urllib3 cookie/auth header leak on cross-origin redirect (CVE-2023-43804)

CVE-2023-43804 is a header-leak vulnerability in urllib3, the HTTP client library that underpins requests, pip, botocore, and a huge share of the Python HTTP ecosystem. The flaw causes urllib3 to keep the Cookie request header attached when a server responds with a redirect (3xx) to a different origin — meaning session cookies, authentication tokens, and other sensitive values set on the original request can be silently forwarded to a host the client never intended to trust. In practice, this turns an innocuous redirect chain (a load balancer, a CDN, a misconfigured proxy, or a malicious endpoint) into a mechanism for exfiltrating credentials to an attacker-controlled server, entirely outside the application's own logic.

The bug sits in one of the most trusted layers of the Python supply chain. Because urllib3 is a transitive dependency of requests — arguably the single most widely used third-party package in the PyPI ecosystem — the practical blast radius extends far past anyone who imports urllib3 directly. Any service, script, SDK, or CLI tool that follows redirects while sending cookies (for session auth, CSRF tokens, or API keys stored in cookie form) is potentially exposed if it sits on a vulnerable urllib3 release.

What Actually Happens

urllib3 already had logic to strip the Authorization header when a redirect changes origin, host, or port — a lesson learned from earlier CVEs in the same header-leak family. CVE-2023-43804 exists because that same sensitive-header treatment was never extended to the Cookie header. When urllib3's redirect handling rebuilds the outgoing request, it treats Cookie as a normal, non-sensitive header and copies it forward unconditionally, even when the Location the server points to resolves to an entirely different domain.

The result is a classic cross-origin information disclosure: an application that trusts example.com to redirect only within itself can be tricked — by a compromised endpoint, an open redirect, or a malicious proxy in the request path — into sending session cookies to evil.example. If those cookies carry session identifiers, bearer-style auth tokens, or CSRF secrets, an attacker capturing them can hijack the session or replay the credential elsewhere.

This is a network- and application-layer issue, not a memory-safety bug, which is why it's often under-prioritized relative to flashier CVEs — but for any service that does cookie-based auth and follows redirects (which is the default behavior in urllib3 and requests), it is a genuine, exploitable data-leak path.

Affected Versions and Components

• urllib3 < 1.26.17 on the 1.x branch
• urllib3 >= 2.0.0, < 2.0.6 on the 2.x branch
• Fixed in urllib3 1.26.17 and urllib3 2.0.6

Because requests vendors urllib3 as a dependency rather than shipping its own HTTP transport, any requests-based application is exposed if its resolved urllib3 version falls in the ranges above. This also cascades into every package that wraps requests or urllib3 directly, including large portions of the botocore/boto3 AWS SDK stack, pip itself, numerous API client SDKs, and countless internal automation and scraping tools. Container images and lockfiles frozen before October 2023 are the most common place this shows up in dependency audits today — it's a textbook example of a vulnerability that "ages" invisibly inside base images and vendored dependency trees long after a fix is public.

It's also worth noting the sibling issue, CVE-2023-45803, disclosed around the same time: urllib3 similarly failed to strip the Proxy-Authorization header on cross-origin redirects through an HTTP proxy. Teams remediating CVE-2023-43804 should patch for both in the same pass, since the fix landed in the same release lines.

Severity: CVSS, EPSS, and KEV Context

NVD scored CVE-2023-43804 as Medium severity, with a CVSS v3.1 base score in the low-to-mid 4.x range, reflecting a network-exploitable, no-privileges-required issue whose impact is scoped to confidentiality (credential/session disclosure) rather than integrity or availability. The score is tempered by the access-complexity requirement that an attacker control or influence a redirect target in the request path — this isn't a "send one packet, own the box" bug, it's a leak that requires a specific request pattern (cookie-bearing request that later redirects cross-origin).

EPSS (Exploit Prediction Scoring System) for this CVE has historically sat in the low single-digit percentile range, consistent with a disclosure-driven, not mass-exploited, vulnerability. It has not appeared on CISA's Known Exploited Vulnerabilities (KEV) catalog as of this writing. That combination — Medium CVSS, low EPSS, not in KEV — is exactly the profile that tends to get deprioritized in ticket queues, which is the real risk: this class of bug is cheap for an attacker to weaponize opportunistically (e.g., pairing it with an open-redirect bug or a compromised upstream service) even if it isn't being mass-scanned today. Supply chain risk doesn't require exploitation volume to matter — it requires the credential to be worth stealing, and session cookies almost always are.

Disclosure Timeline

• Vulnerability identified and reported to the urllib3 maintainers via their private security disclosure process, following the established pattern from earlier Authorization-header-leak fixes in the same codebase.
• October 2023 — urllib3 maintainers publish the fix and coordinate disclosure. urllib3 1.26.17 and urllib3 2.0.6 are released, stripping the Cookie header (and, in the related advisory, Proxy-Authorization) whenever a redirect crosses origin, host, or port boundaries.
• GitHub Security Advisory GHSA-v845-jxx5-vc9f is published, and CVE-2023-43804 is assigned and added to the NVD.
• Downstream propagation follows over subsequent weeks as Linux distributions, container base images, and dependent packages (requests, botocore, and others) bump their pinned urllib3 versions and re-cut releases.
• Ongoing: the CVE continues to surface in SCA and container-image scans years later, because base images and application lockfiles that were never rebuilt after October 2023 still carry the vulnerable range — this is the long tail typical of dependency CVEs versus the initial disclosure spike.

Remediation Steps

1. Upgrade urllib3 directly. Pin to urllib3>=1.26.17,<2.0.0 or urllib3>=2.0.6 depending on which major line your project targets. Don't leave version ranges open-ended in requirements.txt or pyproject.toml for a security-sensitive transport library.
2. Upgrade requests and other wrapping SDKs. Confirm that whatever requests, botocore/boto3, or other client library version you depend on resolves to a patched urllib3 in its own dependency metadata — pinning urllib3 alone doesn't help if a wrapper vendors its own copy or has a conflicting lower bound.
3. Rebuild and re-scan container images. If your base image or a pip install layer was built before October 2023, rebuild it. A vulnerable urllib3 baked into a base image months ago will keep shipping into every derived image until the layer is refreshed.
4. Audit redirect-following behavior in your own code. Anywhere you manually construct sessions, set cookies, or configure allow_redirects=True against endpoints you don't fully control, review whether cookie-bearing requests should follow redirects at all. Where sensitive cookies are involved and the destination isn't guaranteed to stay same-origin, disable automatic redirect following and handle the redirect explicitly, verifying the target origin before resending any credential.
5. Rotate exposed credentials if you suspect prior leakage. If logs show cross-origin redirects on cookie-bearing traffic during the vulnerable window, treat any session tokens or auth cookies used on those requests as potentially disclosed and rotate them.
6. Verify the fix reached runtime, not just the lockfile. A patched version in requirements.txt doesn't guarantee it's what's actually running in production — confirm via pip show urllib3 in the deployed environment or via SBOM analysis against the live artifact.

How Safeguard Helps

Dependency bumps for a CVE like this are easy to write and easy to lose track of across dozens of services, each with its own lockfile, base image, and vendoring quirks — which is exactly the gap Safeguard is built to close. Safeguard generates and ingests SBOMs across your entire fleet so you get a single, continuously updated inventory of exactly where vulnerable urllib3 versions are actually running, not just where they're declared. Griffin AI correlates that inventory with your call graphs and request-handling code paths to flag which services genuinely follow redirects on cookie-bearing requests — reachability analysis that separates "urllib3 is present" from "this cookie-leak path is actually exploitable in your app," so your team fixes what matters first instead of triaging every hit equally. For confirmed, reachable findings, Safeguard can open auto-fix pull requests that bump urllib3 (and any wrapping SDKs) to the patched release across every affected repository, turning a fleet-wide remediation effort into a review-and-merge workflow instead of a manual hunt.