CVE-2026-111063: 
Wolfi vulnerability analysis and mitigation

CVE-2026-111063 is a security feature bypass vulnerability in AIOHTTP, an asynchronous HTTP client/server framework for asyncio and Python, where the Secure attribute for shared cookies (cookies without a Domain attribute) is not enforced by CookieJar.filter_cookies(). This allows shared cookies marked Secure to be transmitted over unencrypted HTTP connections. All versions up to and including 3.14.3 are affected; the issue is fixed in version 3.14.4. It carries a CVSS v3.1 base score of 3.7 (Low) and a CVSS v4.0 base score of 6.3 (Medium) (Github Advisory, Feedly). The vulnerability was reported by euriconicacio and published by Dreamsorcerer on October 7, 2026, with public disclosure on October 19, 2026 (Github Advisory).

The root cause lies in the CookieJar.filter_cookies() method in aiohttp/cookiejar.py, which failed to check the Secure flag before including shared cookies (those stored under the empty-string domain key ("", "")) in outgoing requests over unencrypted HTTP connections (CWE-311: Missing Encryption of Sensitive Data; CWE-319: Cleartext Transmission of Sensitive Information) (Github Advisory). The fix, introduced in commit 999c356, adds a guard that skips any shared cookie with c["secure"] set when the request URL is not HTTPS (is_not_secure check), preventing the cookie from being included in the filtered set (aiohttp commit). Exploitation requires a network-adjacent attacker capable of intercepting unencrypted HTTP traffic (man-in-the-middle position), making the attack complexity high in practice. No special privileges or user interaction are required on the part of the victim application.

Successful exploitation allows an unauthenticated network attacker positioned between the client and server to intercept shared cookies — including session tokens or authentication credentials — that were intended to be transmitted only over encrypted HTTPS connections (Github Advisory, Feedly). The impact is limited to confidentiality (low), with no integrity or availability impact, as the vulnerability only causes unintended disclosure of cookie values over cleartext channels. Applications relying on the Secure flag to protect sensitive shared cookies from interception are most at risk, particularly those operating in environments where HTTP and HTTPS traffic may coexist.

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (Feedly). The EPSS score is 0.0, reflecting a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to be in a network position to intercept unencrypted HTTP traffic (e.g., via ARP spoofing, rogue Wi-Fi, or similar MITM techniques), which raises the practical bar for exploitation.

1. Identify a target application: Locate a Python application using aiohttp versions ≤ 3.14.3 as an HTTP client that sets shared cookies (cookies without a Domain attribute) with the Secure flag.
2. Establish a MITM position: Position yourself on the network path between the aiohttp client and the server using techniques such as ARP spoofing, rogue access point, or DNS manipulation to intercept unencrypted HTTP traffic.
3. Trigger an HTTP request: Cause or wait for the vulnerable aiohttp client to make an HTTP (non-HTTPS) request to any server. Due to the bug, CookieJar.filter_cookies() will include shared cookies marked Secure in the outgoing HTTP request headers.
4. Capture the cookie: Intercept the plaintext HTTP request using a tool such as Wireshark, tcpdump, or mitmproxy and extract the Cookie header containing the Secure-flagged shared cookie value (e.g., session token or authentication credential).
5. Replay or abuse the cookie: Use the captured cookie value to impersonate the victim in subsequent authenticated requests to the target service (Github Advisory, aiohttp commit).

• Network: Unencrypted HTTP requests from an aiohttp client that include a Cookie header containing values expected to be transmitted only over HTTPS (e.g., session tokens, authentication cookies); unexpected HTTP traffic to endpoints that should only be accessed via HTTPS.
• Logs: Application or proxy logs showing HTTP (not HTTPS) requests carrying Cookie headers with Secure-flagged cookie names; network capture logs showing plaintext cookie transmission.
• Process/Application: Aiohttp client applications running versions ≤ 3.14.3 that use shared cookies (set via CookieJar.update_cookies() without a domain URL) with the Secure attribute.

Upgrade aiohttp to version 3.14.4 or later, which contains the fix in commit 999c356 that enforces the Secure attribute for shared cookies in CookieJar.filter_cookies() (aiohttp release, Github Advisory). As a workaround prior to patching, enforce HTTPS-only communication at the application and infrastructure level (e.g., via TLS termination proxies, HSTS headers) to prevent any HTTP requests from being made by the client. Additionally, review cookie configuration to ensure sensitive shared cookies are not used in contexts where HTTP connections are possible.