CVE-2026-69244

The CVSS 7.1 rating for this aiohttp vulnerability is misleading. It's classified as a DoS issue because that's what the reporter demonstrated, but the actual impact is an out-of-bounds heap read that can leak adjacent memory contents—and on persistent HTTP connections, that adjacent memory often contains semantically sensitive data from previous requests on the same socket. The bug lives in aiohttp's error message construction for malformed responses. When llhttp (the C HTTP parser aiohttp wraps) encounters malformed chunked encoding or malformed bytes at the buffer boundary, it returns an error-position pointer. aiohttp's code then uses that pointer to extract a hexdump snippet for the error message—but it never validates that the pointer actually falls within the buffer before using it to index into memory. The result is reading past the buffer boundary into whatever heap allocation happens to be adjacent. This matters most on keep-alive connections. If your aiohttp client has sent authenticated requests to a server and maintains that connection open, the heap buffer holding the response may be adjacent to memory containing authentication headers, session tokens, or remnants of previous request/response pairs. An attacker who controls or compromises the server can trigger the malformed-response condition to read that adjacent memory. You're not just looking at a crash—you're looking at potential credential leakage from previous traffic on the same connection. The fix in version 3.14.3 addresses pointer validation in both parsing contexts (chunked termination and buffer-end malformed bytes), but this is the critical part: older aiohttp branches—3.8.x, 3.9.x, 3.10.x—remain vulnerable and unlikely to receive backports. If you're running any version before 3.14.3, especially in environments where aiohttp clients connect to untrusted or semi-trusted servers, treat this as higher severity than the CVSS suggests. The DoS vector is real but secondary; the data exposure on keep-alive connections is the actual risk. Immediate actions: verify your aiohttp version, upgrade to 3.14.3 or later, and audit any deployments where aiohttp clients maintain persistent connections to servers you don't fully control. Consider rotating credentials that may have been transmitted over long-lived keep-alive connections on vulnerable versions.

Reviewed through automated stages and approved by a human before publication.