CVE-2026-111749 in aiohttp
Summary
by MITRE • 10/19/2026
AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.4, Host-Only scope on an existing parent-domain cookie can be removed by a subdomain. A user who accesses an untrusted subdomain can consequently have host-only protections stripped from cookies, although impact is limited when applications do not reflect those cookies to a browser. This issue is fixed in version 3.14.4.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified within the aiohttp library prior to version 3.14.4 represents a significant deviation from expected cookie scoping behavior, specifically concerning host-only attributes on parent-domain cookies. In standard web security models, cookies are scoped either by domain or by specific host to control their visibility and transmission scope during HTTP requests. A host-only cookie is intended to be sent only to the exact origin that set it, providing a higher level of isolation compared to domain-scoped cookies which may be accessible by subdomains. The flaw in aiohttp allowed for the improper handling of these scopes when interacting with existing parent-domain cookies, effectively stripping or misinterpreting the host-only constraint under certain conditions involving subdomain access.
From a technical perspective, this issue stems from how the library manages cookie storage and retrieval logic within its asynchronous HTTP client implementation. When an application utilizing aiohttp interacts with a URL that belongs to a subdomain of a parent domain where cookies have been previously established, the internal state management fails to correctly preserve the host-only restriction for those specific cookies. This means that instead of treating the cookie as restricted to the original exact host, the library may expose it or allow its transmission in contexts where such exposure violates the intended security boundary defined by the server's Set-Cookie directives. The root cause lies in the parsing and storage mechanisms not strictly enforcing the distinction between domain-level and host-level scoping rules during subsequent requests initiated through subdomains.
The operational impact of this vulnerability is primarily centered around potential information disclosure and session hijacking risks, although the severity is mitigated by application-specific behaviors. If a web application reflects cookie values back to the browser or uses them in ways that make their content visible to client-side scripts or other contexts, an attacker controlling or accessing an untrusted subdomain could exploit this flaw to access sensitive data stored within those cookies. This includes session identifiers, authentication tokens, or personal user information protected by the host-only attribute. However, if the application strictly handles these cookies server-side without reflecting them back to the client in a readable format, the direct impact is limited because the attacker cannot easily extract the cookie contents despite having access via the subdomain vector.
This vulnerability aligns with CWE-16 regarding configuration issues and specifically relates to improper handling of scope constraints for security-critical objects like cookies. It also maps to MITRE ATT&CK techniques involving client-side data exfiltration, particularly where session tokens or authentication credentials are compromised due to insufficient isolation between different subdomains within the same parent domain. The failure to enforce host-only scoping undermines the principle of least privilege applied at the cookie level, allowing lateral movement across subdomain boundaries that should remain isolated.
To mitigate this risk, organizations using aiohttp must ensure they upgrade immediately to version 3.14.4 or later where these scoping rules are correctly enforced. Developers implementing HTTP clients with aiohttp should also audit their code for any reliance on cookie persistence assumptions and consider additional defensive measures such as strict Content Security Policy headers and SameSite cookie attributes to further restrict cross-site request forgery and data leakage vectors. Regular security assessments of third-party library dependencies are essential, especially when dealing with asynchronous frameworks that handle sensitive user state across multiple domain contexts.