Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
MEDIUM severity

`Cookie` HTTP header isn't stripped on cross-origin redirectsGHSA-v845-jxx5-vc9f

MEDIUMFix: urllib3/urllib3@0122035

GHSA-v845-jxx5-vc9f is a medium-severity (CVSS 5.9) Information Exposure vulnerability in urllib3. A fix is available for urllib3 — see the affected versions and patch details below.

Also known asCVE-2023-43804PYSEC-2023-192
Published
Updated
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Oct 23, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
1.4%probability of exploitation in next 30 days
Lower Risk+0.15%
Lower risk than most CVEs72th percentile — riskier than 72% of all scored CVEsHighest risk
0.37%0.86%1.36%1.86%0.9%1.4%Apr 26Aug 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-v845-jxx5-vc9f by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

2 pkgs affected
🐍urllib3🐍urllib3

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

urllib3 doesn't treat the Cookie HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a Cookie header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.

Users must handle redirects themselves instead of relying on urllib3's automatic redirects to achieve safe processing of the Cookie header, thus we decided to strip the header by default in order to further protect users who aren't using the correct approach.

Affected usages

We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited:

  • Using an affected version of urllib3 (patched in v1.26.17 and v2.0.6)
  • Using the Cookie header on requests, which is mostly typical for impersonating a browser.
  • Not disabling HTTP redirects
  • Either not using HTTPS or for the origin server to redirect to a malicious origin.

Remediation

  • Upgrading to at least urllib3 v1.26.17 or v2.0.6
  • Disabling HTTP redirects using redirects=False when sending requests.
  • Not using the Cookie header.

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIurllib3≥ 2.0.0&&< 2.0.62.0.6pip install --upgrade 'urllib3==2.0.6'
🐍PyPIurllib3all versions1.26.17pip install --upgrade 'urllib3==1.26.17'

Affected Products

3 products · 6 configurations
OS
debian linuxdebian
1 version
10.0
OS
fedorafedoraproject
3 versions
373839
Application
urllib3python
≥ 2.0.0 && < 2.0.6
range

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for urllib3, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update urllib3 to 2.0.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v845-jxx5-vc9f is resolved across your whole dependency graph.

  3. Workarounds

    Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatModerate
Workaround published by Red Hat
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
Source: Red Hat security advisory for GHSA-v845-jxx5-vc9f (CC BY 4.0)
ProductFixed inAdvisory
Red Hat Ansible Automation Platform 2.4 for RHEL 8python3x-urllib3-0:1.26.18-1.el8apRHSA-2023:6158
Red Hat Ansible Automation Platform 2.4 for RHEL 8automation-controller-0:4.5.1-1.el8apRHSA-2024:0733
Red Hat Enterprise Linux 8fence-agents-0:4.2.1-121.el8_9.2RHSA-2024:0133
Red Hat Enterprise Linux 8python39:3.9-8100020240214182535.7044f6c1RHSA-2024:2985
Red Hat Enterprise Linux 8python3.11-urllib3-0:1.26.12-2.el8RHSA-2024:2986
Red Hat Enterprise Linux 8python27:2.7-8100020240208011952.5f0f67deRHSA-2024:2987
Red Hat Enterprise Linux 8python-urllib3-0:1.24.2-5.el8_9.2RHSA-2024:0116
Red Hat Enterprise Linux 8.1 Update Services for SAP Solutionsfence-agents-0:4.2.1-30.el8_1.10RHSA-2023:6812
UbuntuMEDIUM
USN-6473-1UbuntuUSN-6473-2Ubuntu

Frequently Asked Questions

urllib3 doesn't treat the `Cookie` HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. Users **must** handle redirects themselves instead of relying on urllib3's automatic redirects to achieve safe processing of the `Cookie` header, thus we decided to strip the header by default in order to further protect users who aren't using the correct appr
O3 Security · Impact-Aware SCA

Is GHSA-v845-jxx5-vc9f in your dependencies?

Find it across PyPI, including transitive dependencies.

Scan my dependencies How O3 SCA works
`Cookie` HTTP header isn't stripped on cross-origin…