aiohttp CVE-2026-111064

Exploitation requires that the aiohttp server is configured with a non-zero keepalive_timeout (the default; the patch notes keepalive_timeout=0 intentionally imposes no first-request deadline) and that attackers can reach the aiohttp listener directly over the network. The specific condition is that, prior to 3.14.4, the keepalive timeout was not armed during the initial phase of a connection, so a client that opens a connection and sends no complete request - or only partial/trickled header bytes - is never timed out. Realistic limiting factors: the vendor's recommended production pattern of a reverse proxy with sensible keepalive limits neutralizes the issue, and a meaningful outage requires the attacker to accumulate many concurrent idle connections to exhaust capacity (reflected by AT:P), so a single connection has negligible impact. Only aiohttp server deployments 3.14.3 and earlier that expose the aiohttp listener directly to untrusted clients are affected.

This is a network-reachable, unauthenticated availability flaw (CWE-770, resource allocation without limits) in the aiohttp Python server. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) scores 8.2 (High) with VA:H as the only impact - confidentiality and integrity are untouched, so the entire severity derives from denial of service. The AT:P (attack requirements present) signal is meaningful: to cause real impact an attacker must open and hold many idle connections to actually exhaust the server's connection capacity, so this is a slowloris-style resource-exhaustion issue rather than a single-request crash. No EPSS score, no CISA KEV listing, and no public exploit were provided in the input; the exploit technique (open a TCP connection, send nothing) is trivial to reproduce but no weaponized PoC is referenced. Net assessment: a genuine availability concern for aiohttp servers directly exposed to untrusted clients, but materially lower priority than a code-execution or data-disclosure bug, and substantially mitigated by the standard production practice of fronting aiohttp with a reverse proxy - the vendor's own recommended workaround. EPSS is absent, so widespread automated exploitation cannot be confirmed; treat as patch-on-maintenance-cycle unless the server is internet-facing without a proxy.

An attacker opens numerous TCP connections to an internet-facing aiohttp server (3.14.3 or earlier) and simply never sends request data - or trickles header bytes slowly - keeping each connection idle indefinitely because the keepalive timeout was not applied before the first complete request arrived. By accumulating enough held-open connections, the attacker exhausts the server's connection-handling capacity and denies service to legitimate users. No authentication or user interaction is required, though no public weaponized exploit is referenced in the input.