Track vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
7.5
Scrapy may run code from malicious Referrer-Policy header
published 7 months ago
Summary
Scrapy versions 1.4.0 and later read the Referrer-Policy response header and, if it looks like a Python import path, automatically load and execute that code. A crafted header such as "sys.exit" could cause the Scrapy process to stop or run unwanted code. Upgrade to Scrapy 2.14.2 or later, or disable the referer middleware and set the header manually if you cannot upgrade.
What to do
- Update scrapy developers scrapy to version 2.14.2.
- Update scrapy to version 2.14.2.
Affected software
| Ecosystem | Vendor | Product | Affected versions |
|---|---|---|---|
| PyPI | scrapy developers | scrapy |
>= 1.4.0, < 2.14.2 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.
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
Published13 Mar 2026
Updated21 Oct 2026
First seen5 Oct 2026
Sources
GHSA-cwxj-rr6w-m6w7 · OSV
Track software like this
Free during beta