Track vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
7.5
CVE-2026-105782: Scrapy may run arbitrary code from Referrer-Policy header
CVE-2026-105782 · published 20 days ago
Summary
Scrapy versions from 1.4.0 allow a web page to tell the crawler to import and execute any Python object named in the Referrer-Policy response header. An attacker could use this to stop the crawler or run unwanted code. Upgrade to Scrapy 2.14.2 or later, or disable the Referer middleware and set the header manually as a workaround.
What to do
- Update scrapy developers scrapy to version 2.14.2.
- Update debian python-scrapy to version 2.14.2-1.
- Update scrapy to version 2.14.2.
Affected software
| Ecosystem | Vendor | Product | Affected versions |
|---|---|---|---|
| pip | scrapy developers | scrapy |
>= 1.4.0, <= 2.14.1 Fix: upgrade to 2.14.2
|
| Debian:12 | debian | python-scrapy | All versions |
| Debian:14 | debian | python-scrapy |
< 2.14.2-1 Fix: upgrade to 2.14.2-1
|
| Ubuntu:16.04:LTS | canonical | python-scrapy | All versions |
| pip | – | scrapy |
>= 1.4.0, <= 2.14.1 Fix: upgrade to 2.14.2
|
| PyPI | – | scrapy |
>= 1.4.0, < 2.14.2 Fix: upgrade to 2.14.2
|
Original advisory text
Scrapy: Arbitrary Module Import via Referrer-Policy Header in RefererMiddleware
### Impact
Since version 1.4.0, Scrapy respects the `Referrer-Policy` response header to decide whether and how to set a `Referer` header on follow-up requests.
If the header value looked like a valid Python import path, Scrapy would import the referenced object and call it, assuming it referred to a referrer policy class (for example, `scrapy.spidermiddlewares.referer.DefaultReferrerPolicy`) and attempting to instantiate it to handle the `Referer` header.
A malicious site could exploit this by setting `Referrer-Policy` to a path such as `sys.exit`, causing Scrapy to import and execute it and potentially terminate the process.
### Patches
Upgrade to Scrapy 2.14.2 (or later).
### Workarounds
If you cannot upgrade to Scrapy 2.14.2, consider the following mitigations.
- **Disable the middleware:** If you don't need the `Referer` header on follow-up requests, set [`REFERER_ENABLED`](https://docs.scrapy.org/en/latest/topics/spider-middleware.html#referer-enabled) to `False`.
- **Set headers manually:** If you do need a `Referer`, disable the middleware and set the header explicitly on the requests that require it.
- **Set `referrer_policy` in request metadata:** If disabling the middleware is not viable, set the [`referrer_policy`](https://docs.scrapy.org/en/latest/topics/spider-middleware.html#referrer-policy) request meta key on all requests to prevent evaluating preceding responses' `Referrer-Policy`. For example:
```python
Request(
url,
meta={
"referrer_policy": "scrapy.spidermiddlewares.referer.DefaultReferrerPolicy",
},
)
```
Instead of editing requests individually, you can:
- implement a custom [spider middleware](https://docs.scrapy.org/en/latest/topics/spider-middleware.html) that runs before the built-in referrer policy middleware and sets the `referrer_policy` meta key; or
- set the meta key in start requests and use the [scrapy-sticky-meta-params](https://github.com/heylouiz/scrapy-sticky-meta-params) plugin to propagate it to follow-up requests.
If you want to continue respecting legitimate `Referrer-Policy` headers while protecting against malicious ones, disable the built-in referrer policy middleware by setting it to `None` in [`SPIDER_MIDDLEWARES`](https://docs.scrapy.org/en/latest/topics/settings.html#std-setting-SPIDER_MIDDLEWARES) and replace it with the fixed implementation from Scrapy 2.14.2.
If the Scrapy 2.14.2 implementation is incompatible with your project (for example, because your Scrapy version is older), copy the corresponding middleware from your Scrapy version, apply the same patch, and use that as a replacement.
Since version 1.4.0, Scrapy respects the `Referrer-Policy` response header to decide whether and how to set a `Referer` header on follow-up requests.
If the header value looked like a valid Python import path, Scrapy would import the referenced object and call it, assuming it referred to a referrer policy class (for example, `scrapy.spidermiddlewares.referer.DefaultReferrerPolicy`) and attempting to instantiate it to handle the `Referer` header.
A malicious site could exploit this by setting `Referrer-Policy` to a path such as `sys.exit`, causing Scrapy to import and execute it and potentially terminate the process.
### Patches
Upgrade to Scrapy 2.14.2 (or later).
### Workarounds
If you cannot upgrade to Scrapy 2.14.2, consider the following mitigations.
- **Disable the middleware:** If you don't need the `Referer` header on follow-up requests, set [`REFERER_ENABLED`](https://docs.scrapy.org/en/latest/topics/spider-middleware.html#referer-enabled) to `False`.
- **Set headers manually:** If you do need a `Referer`, disable the middleware and set the header explicitly on the requests that require it.
- **Set `referrer_policy` in request metadata:** If disabling the middleware is not viable, set the [`referrer_policy`](https://docs.scrapy.org/en/latest/topics/spider-middleware.html#referrer-policy) request meta key on all requests to prevent evaluating preceding responses' `Referrer-Policy`. For example:
```python
Request(
url,
meta={
"referrer_policy": "scrapy.spidermiddlewares.referer.DefaultReferrerPolicy",
},
)
```
Instead of editing requests individually, you can:
- implement a custom [spider middleware](https://docs.scrapy.org/en/latest/topics/spider-middleware.html) that runs before the built-in referrer policy middleware and sets the `referrer_policy` meta key; or
- set the meta key in start requests and use the [scrapy-sticky-meta-params](https://github.com/heylouiz/scrapy-sticky-meta-params) plugin to propagate it to follow-up requests.
If you want to continue respecting legitimate `Referrer-Policy` headers while protecting against malicious ones, disable the built-in referrer policy middleware by setting it to `None` in [`SPIDER_MIDDLEWARES`](https://docs.scrapy.org/en/latest/topics/settings.html#std-setting-SPIDER_MIDDLEWARES) and replace it with the fixed implementation from Scrapy 2.14.2.
If the Scrapy 2.14.2 implementation is incompatible with your project (for example, because your Scrapy version is older), copy the corresponding middleware from your Scrapy version, apply the same patch, and use that as a replacement.
References
- https://nvd.nist.gov/vuln/detail/CVE-2026-105782 Vendor Advisory
- https://github.com/scrapy/scrapy/security/advisories/GHSA-cwxj-rr6w-m6w7 URL
- https://ubuntu.com/security/CVE-2026-105782 Third Party Advisory
- https://www.cve.org/CVERecord?id=CVE-2026-105782 Third Party Advisory
- https://github.com/scrapy/scrapy/commit/b6e5c58ae707a3d4bb491537b5519534050047e0 Patch
- https://github.com/scrapy/scrapy/commit/945b787a263586cb5803c01c6da57daad8997ae5 URL
- https://github.com/advisories/GHSA-cwxj-rr6w-m6w7 Vendor Advisory
- https://security-tracker.debian.org/tracker/CVE-2026-105782 Vendor Advisory
- https://github.com/scrapy/scrapy Product
- https://pypi.org/project/scrapy Product
- https://github.com/scrapy/scrapy/releases/tag/2.14.2 URL
- https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/105xxx/CVE-2026-1057... Vendor Advisory
Internet-facing
14 days
Internal
60 days
- Not known to be exploited
- Can be exploited automatically
- Gives an attacker partial control
Type
CWE-470Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
Timeline
Published15 Oct 2026
Updated21 Oct 2026
First seen13 Mar 2026
Sources
GHSA-cwxj-rr6w-m6w7 · GHSA
CVE-2026-105782 · OSV
DEBIAN-CVE-2026-105782 · OSV
UBUNTU-CVE-2026-105782 · OSV
PYSEC-2026-4299 · OSV
Track software like this
Free during beta