CVE-2026-47265: Cross-Origin Cookie Leakage in AIOHTTP Client Redirects

The AIOHTTP asynchronous HTTP client framework for Python is widely utilized in microservice architectures, web scrapers, and automated integration pipelines. When executing outbound HTTP requests, applications frequently handle stateful sessions using cookies. AIOHTTP manages these credentials using either a session-level global cookie jar or request-specific parameters.

This vulnerability lies within the origin validation boundaries of the redirect resolution process. Specifically, when an HTTP request initiated by an AIOHTTP client receives an automatic redirect status code, the library resolves the new location and determines if the destination resides on a different origin.

If the redirect target constitutes a different origin (by scheme, host, or port), the framework is designed to sanitize the outgoing request to prevent credential disclosure. However, under CWE-346 (Origin Validation Error), the sanitization logic fails to address request-specific local variables. Consequently, sensitive authentication tokens are unintentionally forwarded to untrusted external domains.

To understand the root cause, it is necessary to examine how AIOHTTP isolates request-specific state. When invoking client requests via ClientSession._request(), a developer can supply cookies using the cookies argument, such as session.get(url, cookies={'session_id': 'secret'}). These arguments are handled locally within the request lifecycle rather than being merged into the persistent, domain-constrained CookieJar class.

When a remote server issues a redirect response (e.g., 301, 302, or 307) and redirection is enabled, the client framework executes a loop in _connect_and_send_request to dispatch subsequent queries. During a cross-origin transition, the following logical evaluation is performed:

if url.origin() != redirect_origin:
    auth = None
    headers.pop(hdrs.AUTHORIZATION, None)
    headers.pop(hdrs.COOKIE, None)
    headers.pop(hdrs.PROXY_AUTHORIZATION, None)

While this sanitization process successfully purges standard HTTP headers like Authorization and Cookie from the request headers dictionary, it fails to alter or nullify the local cookies variable. Because this variable remains bound to the execution scope of the loop, it is passed directly into the subsequent ClientRequest constructor for the new, cross-origin URL. The constructor then generates a new Cookie header from this pristine local variable and transmits it to the external destination.

The official patch introduced in commit f54c40851b0d6c4bbdab97ba518a223adda32478 resolves the bug by explicitly purging the local cookies variable alongside standard HTTP headers.

# Source: aiohttp/client.py
@@ -971,6 +971,7 @@ async def _connect_and_send_request(
 
                         if url.origin() != redirect_origin:
                             auth = None
+                            cookies = None
                             headers.pop(hdrs.AUTHORIZATION, None)
                             headers.pop(hdrs.COOKIE, None)
                             headers.pop(hdrs.PROXY_AUTHORIZATION, None)

By adding cookies = None, the client ensures that the subsequent call to the ClientRequest constructor receives an empty state for the per-request cookies parameter, preventing the re-creation of the Cookie header.

While this fix is highly effective at stopping parameter leakage, security engineers must remain aware of adjacent attack surfaces. Specifically, the origin validation relies on the yarl library's url.origin() method. Parser differentials between yarl and downstream socket resolution libraries regarding malformed URLs or Unicode Internationalized Domain Names (IDNs) could hypothetically still lead to origin confusion. Additionally, custom API authorization headers, such as X-API-Key or X-Auth-Token, are not explicitly stripped by this logic and will continue to propagate across redirects.

An exploitation scenario requires an attacker to control or influence the redirect destination of an HTTP request initiated by an AIOHTTP client. This is common in server-side request forgery (SSRF) entry points, webhook processing systems, or open-redirect vulnerabilities hosted on a target domain.

To exploit this vulnerability, an attacker can manipulate an API endpoint to return a redirect response to an attacker-controlled server. If the vulnerable client executes the request using local parameters, the credentials are automatically leaked to the attacker's endpoint:

# Vulnerable configuration
async with aiohttp.ClientSession() as session:
    # Under affected versions, the cookie below is forwarded to attacker.com upon redirection
    await session.get("https://target.com/api", cookies={"session_id": "SECRET"})

When the client encounters a 302 Found directing it to https://attacker.com, it automatically connects to the external server. The server's connection log then captures the incoming request containing the valid, unexpired Cookie: session_id=SECRET header.

The potential impact of this vulnerability depends on the lifecycle and privilege level of the leaked cookies. If the client uses session identifiers, administrative JSON Web Tokens (JWTs), or authentication cookies to communicate with stateful APIs, an attacker gaining these values can perform session hijacking or unauthorized API transactions.

This vulnerability has been assigned a CVSS v4.0 score of 6.6 (Medium) with a vector of CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U. The confidentiality impact on the client execution environment is marked as High because authentication tokens can be recovered by unauthorized external entities.

Currently, the Exploit Prediction Scoring System (EPSS) score remains low at 0.00019 (0.019% probability), reflecting the absence of weaponized public exploits or active exploitation in the wild. Nonetheless, applications performing high-volume server-side HTTP client requests are at distinct risk if they process dynamic redirects without strict input sanitization.

The definitive resolution for CVE-2026-47265 is upgrading the aiohttp library to version 3.14.0 or later. This ensures that the framework's internal redirection logic correctly purges local cookies prior to executing cross-origin requests.

pip install --upgrade aiohttp>=3.14.0

For environments where an immediate library upgrade is not feasible, developers must refactor request invocations to construct the standard Cookie header explicitly within the headers argument rather than relying on the cookies argument. This ensures that existing header-clearing routines remove the sensitive data before cross-origin requests are dispatched:

# INSECURE pattern in < 3.14.0
await session.get("https://target.com", cookies={"token": "secret"})
 
# SECURE workaround pattern in all versions
headers = {"Cookie": "token=secret"}
await session.get("https://target.com", headers=headers)

Additionally, implementing a strict egress control policy or disabling redirects (allow_redirects=False) on requests containing sensitive credentials provides an extra layer of defense.