aiohttp CVE-2026-111748

Exploitation requires three concrete conditions. First, the target must run an aiohttp web server at a version prior to 3.14.4. Second, the attacker must send an HTTP/1.1 request using absolute-form request-target syntax (e.g. 'GET https://host/path HTTP/1.1' or 'http://...') so that a scheme is embedded in the target. Third - the key limiting factor captured by the CVSS AT:P metric - the application code must use Request.scheme to make a security decision (such as setting the Secure flag on cookies, enforcing or redirecting to HTTPS, or deciding whether a connection is trusted); applications that never read Request.scheme for security purposes are unaffected. No authentication and no user interaction are required (PR:N/UI:N), but the dependency on application-side use of Request.scheme materially narrows real-world exploitability.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N, base 6.3 Medium) paints a consistent picture of a network-reachable, unauthenticated flaw with low confidentiality and integrity impact and - critically - an attack requirement (AT:P) that reflects the real precondition: the target application must actually consume Request.scheme to make a security decision. This AT:P metric is the single most important signal, because it explains why a 'network/unauthenticated' bug is only Medium rather than Critical - the aiohttp parser bug is necessary but not sufficient on its own. There is no exploitation status to confirm: KEV is not listed, no POC is referenced, and no EPSS probability was supplied in the input, so exploitation likelihood cannot be quantified from the data given and should not be assumed high. Signals are internally consistent (no CVSS-vs-description conflict), but the EPSS score is MISSING and cannot be inferred. Net assessment: this is a legitimate but conditional transport-security-downgrade/upgrade issue rather than a broad-impact remote code execution - a real priority only for the subset of aiohttp deployments whose application logic trusts Request.scheme for cookie-secure flags, HTTPS enforcement, or redirect decisions.

An attacker sends a crafted absolute-form request-target (e.g. 'GET https://victim/path HTTP/1.1') over a plaintext HTTP connection to an aiohttp web server prior to 3.14.4. Because the parser trusts the scheme embedded in the request-target rather than the actual connection protocol, an application that checks Request.scheme to decide whether the connection is secure is tricked into treating the unencrypted request as HTTPS (or vice-versa), bypassing secure-cookie, HSTS, or HTTPS-redirect logic. No public exploit code is identified, and success depends on the application relying on Request.scheme for a security decision.