CVE-2026-34518

What it actually does

Prior to aiohttp 3.13.4, the HTTP client incorrectly preserves Cookie and Proxy-Authorization headers when automatically following an HTTP redirect to a different origin. Although the Authorization header is stripped, cookies scoped by the client and proxy credentials can be sent to an attacker-controlled or unintended host after a cross-origin 3xx redirect. This is an information disclosure issue affecting applications that use aiohttp as an HTTP client with automatic redirects enabled and that attach Cookie or Proxy-Authorization headers to outbound requests.

Why it matters to the business

Applications using vulnerable aiohttp versions may unintentionally disclose session cookies, authentication tokens stored in cookies, or proxy credentials to external systems. In business terms, this can enable account takeover, unauthorized access to upstream services, exposure of internal proxy infrastructure, or leakage of sensitive integration credentials. The CVSS score is moderate and EPSS is currently low, with no known KEV listing or ransomware association, but exposure can still be serious where aiohttp is used for service-to-service requests, API integrations, scraping, webhooks, or internal automation that follows redirects.

How an attack unfolds

An attacker first identifies an application or workflow that uses aiohttp to fetch attacker-influenced URLs or URLs hosted by a service the attacker can control. The attacker causes the initial request to receive a redirect response, such as HTTP 301, 302, 303, 307, or 308, pointing to a different origin under the attacker’s control. If the aiohttp client request includes Cookie or Proxy-Authorization headers and automatic redirect following is enabled, vulnerable versions drop the Authorization header but incorrectly retain the Cookie and Proxy-Authorization headers on the redirected request. The attacker’s server then receives and records those headers. Depending on what the leaked values represent, the attacker may reuse them to access user sessions, impersonate service accounts, authenticate through a proxy, or pivot into other systems that trust those credentials.

How to fix it

Upgrade aiohttp to version 3.13.4 or later wherever it is used. Because the provided package metadata does not list per-package fixed versions, use the upstream patched version from the advisory: aiohttp 3.13.4. Update direct dependencies, lockfiles, container images, serverless deployment packages, build caches, and vendored Python environments. If immediate upgrade is not possible, disable automatic redirect following for sensitive requests, manually validate redirect targets before following them, strip Cookie and Proxy-Authorization headers before any cross-origin redirect, and avoid sending proxy credentials or session cookies on requests to attacker-influenced URLs. Also review whether outbound requests should be restricted to explicit allowlisted domains.

How to confirm the fix worked

Confirm that all runtime environments use aiohttp 3.13.4 or later by checking package inventories, lockfiles, container SBOMs, and runtime package versions. Useful checks include `python -c "import aiohttp; print(aiohttp.__version__)"`, `pip show aiohttp`, `pip freeze | grep aiohttp`, and inspection of `poetry.lock`, `Pipfile.lock`, `requirements*.txt`, and container image SBOMs. To validate behavior dynamically, create a test endpoint that redirects from one origin to another and send a request with Cookie and Proxy-Authorization headers using the application’s aiohttp path; the redirected request to the second origin must not include those headers. Also verify that security scanners and dependency management tools no longer report vulnerable aiohttp versions.

Typical attack path

1. Identify an application, integration, crawler, webhook processor, or backend workflow that uses aiohttp to make outbound HTTP requests.
2. Find a way to influence the destination URL or the HTTP response returned by a destination the aiohttp client contacts.
3. Return a cross-origin redirect to an attacker-controlled host.
4. Allow the vulnerable aiohttp client to automatically follow the redirect.
5. Capture leaked Cookie or Proxy-Authorization headers on the attacker-controlled redirect destination.
6. Reuse the exposed cookie or proxy credential where valid, or sell/relay it for further intrusion.

How to detect it

To determine whether exploitation already occurred, review outbound HTTP client logs, reverse proxy logs, egress proxy logs, WAF logs, DNS logs, and destination server logs for redirect chains where an initial request to one origin is followed by a request to a different origin that includes Cookie or Proxy-Authorization headers. Focus on applications using aiohttp before 3.13.4, especially URL fetchers, webhook processors, API clients, scrapers, and automation that accepts third-party URLs. Look for 3xx responses to external domains followed immediately by outbound requests from the same application instance, source IP, user agent, trace ID, or request correlation ID. Investigate any external destination receiving cookies or Proxy-Authorization values that should only be used with an original service or internal proxy. If full HTTP header logging is unavailable, correlate unusual cross-origin redirect activity with subsequent suspicious session use, unexpected proxy authentication, anomalous egress destinations, or authentication events using cookies shortly after redirect chains. Because no public exploit tooling or unique malware artifacts are known from the provided data, detection is primarily behavioral and log-correlation based rather than signature-based.

What your security team should do

• Prioritize upgrading all aiohttp installations to 3.13.4 or later, especially internet-facing services, URL fetchers, webhook handlers, crawlers, and backend integrations that follow redirects.
• Inventory applications and containers that include aiohttp, including transitive dependencies and vendored Python packages.
• Identify workflows that fetch user-supplied or third-party URLs and determine whether they send Cookie or Proxy-Authorization headers.
• Temporarily disable automatic redirects or enforce same-origin redirect policies for sensitive outbound requests until upgrades are complete.
• Rotate cookies, session tokens, or proxy credentials that may have been exposed through cross-origin redirects, prioritizing high-privilege integrations.
• Add outbound egress monitoring for unexpected cross-origin redirect chains carrying Cookie or Proxy-Authorization headers.
• Create regression tests to ensure sensitive headers are stripped whenever redirects cross scheme, host, or port boundaries.