CVE-2026-111063 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, the Secure attribute for a shared cookie is not enforced. An attacker can consequently cause a shared cookie marked Secure to be sent with an unencrypted request. This issue is fixed in version 3.14.4.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/19/2026
The AIOHTTP library serves as a foundational asynchronous HTTP client and server framework for Python, leveraging the asyncio event loop to handle network operations efficiently. In versions prior to 3.14.4, a critical security flaw exists within its cookie handling mechanism regarding the enforcement of the Secure attribute on shared cookies. The Secure flag is an essential component of web application security architecture, designed explicitly to prevent sensitive session identifiers or authentication tokens from being transmitted over unencrypted HTTP connections. When this attribute is set on a cookie, it signals that the browser should only send the cookie back to the server if the communication channel utilizes HTTPS with valid TLS encryption. The vulnerability arises because AIOHTTP failed to strictly enforce this constraint for shared cookies, allowing them to be included in requests made over plain HTTP.
This technical flaw constitutes an improper enforcement of security restrictions on data handling, specifically categorized under CWE-16: Configuration. By failing to respect the Secure flag, the library inadvertently facilitates the exposure of sensitive session state information. An attacker positioned within a network path capable of intercepting unencrypted traffic can exploit this behavior through man-in-the-middle attacks or passive sniffing. Since shared cookies often contain critical authentication credentials such as session IDs, tokens, or user identifiers, their transmission over an insecure channel renders them vulnerable to interception. This exposure directly undermines the confidentiality and integrity guarantees provided by TLS, effectively nullifying the protective intent of using HTTPS for those specific requests where the cookie was inadvertently sent in plaintext.
The operational impact of this vulnerability is significant for applications relying on AIOHTTP for secure API communications or web service interactions. If an application uses shared cookies to maintain user sessions across multiple subdomains or services, and one of these endpoints does not enforce HTTPS while another does, the Secure flag should prevent leakage from the insecure endpoint. However, due to this bug, even if some parts of the infrastructure are secured with TLS, the cookie data remains exposed on unsecured connections. This can lead to session hijacking attacks where an attacker captures a valid session ID and uses it to impersonate the legitimate user. Furthermore, in environments where mixed content or legacy systems still utilize HTTP alongside HTTPS, this flaw creates a persistent attack surface that security audits might otherwise overlook if they assume standard cookie behavior is correctly implemented by all libraries.
To mitigate this risk, organizations utilizing AIOHTTP must upgrade immediately to version 3.14.4 or later, which includes the necessary code changes to enforce the Secure attribute properly for shared cookies. For applications running on older versions that cannot be updated instantly due to compatibility constraints, developers should implement strict URL validation logic within their application layer to ensure that any request containing sensitive cookies is explicitly verified against a whitelist of HTTPS endpoints before transmission. Additionally, implementing HTTP Strict Transport Security headers where applicable can help enforce secure connections at the server level, reducing the likelihood of accidental unencrypted requests being made by clients or internal services. Regular security assessments and dependency scanning should be conducted to ensure that all third-party libraries are kept up-to-date with their latest security patches, thereby maintaining a robust defense-in-depth posture against network-level interception attacks as defined in MITRE ATT&CK techniques related to credential access via intercepted communications.