aiohttp EUVD-2026-104478

Requires a specific combination: (1) the aiohttp CookieJar holds a 'shared' cookie - one set without a Domain attribute - that carries the Secure attribute; (2) the application subsequently makes a request over an unencrypted http:// connection to that host; and (3) an attacker occupies an on-path/man-in-the-middle position able to observe the cleartext request. LIMITING FACTORS: only Secure cookies that are also shared (no Domain) are affected - domain-scoped Secure cookies are unaffected; exploitation yields only passive disclosure of the cookie value, not code execution or tampering; and it depends on the application actually initiating a cleartext request, so deployments that exclusively use https:// are not exposed. No end-user interaction or authentication is needed, but network interception capability is mandatory.

This is a moderate, information-disclosure flaw (CWE-311) rather than a high-urgency priority. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N) scores 6.3 (medium) and is internally consistent with the description: the AT:P (attack requirements present) metric captures the fact that the attacker cannot simply trigger this remotely but must be positioned to observe the unencrypted traffic, and VC:L with VI:N/VA:N correctly reflects a limited confidentiality-only impact (leak of one cookie value) with no integrity or availability effect. Exploitation status: no public exploit identified at time of analysis - no CISA KEV listing and no POC was provided in the intelligence. EPSS is not supplied, so probability-of-exploitation cannot be quantified; however, the narrow preconditions (a shared Secure cookie plus an on-path attacker plus the application actually making a cleartext request to the cookie's host) make opportunistic mass exploitation unlikely. There is no conflict between the signals here, but note one caveat: the single CVSS vector provided is CVSS 4.0 only - no CVSS 3.1 vector and no EPSS/SSVC data accompany it, so real-world prioritization rests on the vector plus the confirmed patch metadata. Overall this is a 'defense-in-depth' cookie-handling regression, not a critical remote-code or mass-exploitation issue.

An application uses aiohttp's client CookieJar containing a shared cookie (one with no Domain attribute) marked Secure, and the application issues a request to an http:// (unencrypted) URL for that host. In versions ≤ 3.14.3, aiohttp's filter_cookies() wrongly attaches the Secure cookie to that cleartext request, so an attacker positioned on the network path (passive sniffing or active MITM) reads the cookie value from the plaintext traffic. No public exploit code was identified in the provided data.