# GHSA-9x8m-2xpf-crp3: Scrapy before 2.6.2 and 1.8.3 vulnerable to one proxy sending credentials to another

> Scrapy leaks proxy credentials to different proxies during rotation, exposing sensitive authentication data to unintended third parties.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 29 Jul 2022

## What is GHSA-9x8m-2xpf-crp3?

GHSA-9x8m-2xpf-crp3 is a vulnerability in scrapy, published on 29 Jul 2022. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

### Impact

When the [built-in HTTP proxy downloader middleware](https://docs.scrapy.org/en/2.6/topics/downloader-middleware.html#module-scrapy.downloadermiddlewares.httpproxy) processes a request with `proxy` metadata, and that `proxy` metadata includes proxy credentials, the built-in HTTP proxy downloader middleware sets the `Proxy-Authentication` header, but only if that header is not already set.

There are third-party proxy-rotation downloader middlewares that set different `proxy` metadata every time they process a request.

Because of request retries and redirects, the same request can be processed by downloader middlewares more than once, including both the built-in HTTP proxy downloader middleware and any third-party proxy-rotation downloader middleware.

These third-party proxy-rotation downloader middlewares could change the `proxy` metadata of a request to a new value, but fail to remove the `Proxy-Authentication` header from the previous value of the `proxy` metadata, causing the credentials of one proxy to be leaked to a different proxy.

If you rotate proxies from different proxy providers, and any of those proxies requires credentials, you are affected, unless you are handling proxy rotation as described under **Workarounds** below. If you use a third-party downloader middleware for proxy rotation, the same applies to that downloader middleware, and installing a patched version of Scrapy may not be enough; patching that downloader middlware may be necessary as well.

### Patches

Upgrade to Scrapy 2.6.2.

If you are using Scrapy 1.8 or a lower version, and upgrading to Scrapy 2.6.2 is not an option, you may upgrade to Scrapy 1.8.3 instead.

### Workarounds

If you cannot upgrade, make sure that any code that changes the value of the `proxy` request meta also removes the `Proxy-Authorization` header from the request if present.

### For more information

If you have any questions or comments about this advisory:
* [Open an issue](https://github.com/scrapy/scrapy/issues)
* [Email us](mailto:opensource@zyte.com)

## Which versions are affected by GHSA-9x8m-2xpf-crp3?

4 open source packages ship an affected version, including scrapy.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `scrapy` | PyPI | All versions | 1.8.3 |
| `scrapy` | PyPI | All versions | 1.8.3 |
| `scrapy` | PyPI | From 2.0.0 | 2.6.2 |
| `scrapy` | PyPI | From 2.0.0 | 2.6.2 |

## How do I fix GHSA-9x8m-2xpf-crp3?

Upgrade scrapy to a fixed version for your release line: 1.8.3 or 2.6.2.

## Is GHSA-9x8m-2xpf-crp3 being exploited?

There is no known exploitation of GHSA-9x8m-2xpf-crp3 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-9x8m-2xpf-crp3 and fix it if it is affected.

What it is: GHSA-9x8m-2xpf-crp3 is a vulnerability in scrapy, published on 29 Jul 2022. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-9x8m-2xpf-crp3 in the wild and no public exploit code.

Affected packages and fixed versions:
- scrapy (PyPI): affected all versions; fixed in 1.8.3
- scrapy (PyPI): affected all versions; fixed in 1.8.3
- scrapy (PyPI): affected from 2.0.0; fixed in 2.6.2
- scrapy (PyPI): affected from 2.0.0; fixed in 2.6.2

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-9x8m-2xpf-crp3/ (Markdown: https://insights.sbomify.com/GHSA-9x8m-2xpf-crp3/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-9x8m-2xpf-crp3

---
From sbomify Insights: https://insights.sbomify.com/GHSA-9x8m-2xpf-crp3/
Summaries are generated and may contain mistakes; the official description above is the record.