CVE-2026-34519

What it actually does

AIOHTTP versions prior to 3.13.4 do not sufficiently validate the HTTP response reason phrase when creating a Response. If an application allows attacker-controlled input to reach the Response reason parameter, the attacker may inject carriage return/line feed characters or other header-like content into the HTTP response. This can result in HTTP response splitting or unintended header injection, allowing limited modification of response metadata such as cookies, redirects, cache directives, security headers, or similar client/proxy-visible headers. The flaw does not by itself provide code execution or direct data disclosure; impact depends on whether the vulnerable application exposes attacker-controlled reason values and how downstream clients, browsers, caches, and proxies process the malformed response.

Why it matters to the business

Applications built on vulnerable AIOHTTP versions may be exposed to response manipulation if they pass untrusted input into response reason phrases. Successful exploitation could enable session disruption, malicious redirects, cache poisoning, weakening of browser security controls, or insertion of misleading response headers. The CVSS score is moderate and EPSS is currently low, with no known CISA KEV listing or ransomware association, but the package is a common Python web framework component, so organizations should still prioritize patching internet-facing services and any service that reflects user-controlled values into HTTP responses.

How an attack unfolds

An attacker first identifies an AIOHTTP-based endpoint where some user-controllable value is used as the Response reason parameter, either directly or through application error handling. The attacker then submits a crafted value containing CRLF sequences followed by header syntax, such as an injected Set-Cookie, Location, Cache-Control, or security-header override. In vulnerable versions, AIOHTTP may construct the HTTP response without adequately rejecting or sanitizing the reason phrase, causing the injected content to be interpreted by some clients, intermediaries, or logging systems as additional headers or response metadata. The practical result depends on surrounding application behavior: an attacker may poison a shared cache, force a client-side redirect, set or overwrite cookies, weaken browser protections, or confuse downstream security devices. Exploit maturity is reported as none and there is no known KEV exploitation at this time, so exploitation is most likely to appear as probing for CRLF/header injection in parameters that influence server responses.

How to fix it

Upgrade AIOHTTP to version 3.13.4 or later wherever it is used. If immediate upgrade is not possible, ensure applications never pass untrusted input to the Response reason parameter, enforce strict allowlists for reason phrases, and reject any value containing carriage return, line feed, or other control characters. Review custom response builders, exception handlers, middleware, and error-formatting code for use of aiohttp.web.Response(reason=...). Add defense-in-depth controls at reverse proxies or WAFs to block CRLF sequences in request parameters that are not explicitly required. Rebuild and redeploy affected Python application containers, virtual environments, and dependency lockfiles so runtime packages actually contain the patched version.

How to confirm the fix worked

Confirm that all deployed Python environments, containers, and build artifacts use aiohttp 3.13.4 or later by checking package metadata with commands such as `python -m pip show aiohttp`, `python -m pip freeze`, Poetry lockfiles, Pipenv lockfiles, requirements files, SBOMs, and container image scans. Validate application code paths by searching for `Response(`, `web.Response(`, and `reason=` and confirming that no untrusted input reaches the reason parameter. Where safe in a test environment, submit a reason-influencing value containing encoded CRLF such as `%0d%0aX-Test-Injected:%20true` and confirm the response does not contain an injected `X-Test-Injected` header. Also verify reverse proxies, API gateways, and WAFs reject or normalize CRLF-bearing requests as expected.

Typical attack path

1. Find an application or API endpoint implemented with AIOHTTP prior to version 3.13.4.
2. Identify input that is reflected into, or influences, the HTTP response reason phrase, commonly through custom error handling or response construction.
3. Send a crafted request containing CRLF sequences and header-like payloads such as Set-Cookie, Location, Cache-Control, Content-Security-Policy, or Access-Control-Allow-Origin.
4. Cause the vulnerable server to emit a malformed HTTP response where the injected content appears as additional headers or response metadata.
5. Abuse the injected headers to manipulate browser behavior, poison intermediary caches, alter cookies, trigger redirects, or bypass intended client-side security controls.

How to detect it

To determine whether exploitation was attempted or successful, review HTTP access logs, reverse proxy logs, WAF/API gateway events, load balancer logs, and AIOHTTP application logs for requests containing raw or encoded carriage-return/line-feed sequences followed by header-like names. Focus on parameters, paths, form fields, JSON fields, and error-triggering requests that include `%0d%0a`, `%0a`, `%0d`, `\r\n`, or unusual header strings such as `Set-Cookie:`, `Location:`, `Cache-Control:`, `Content-Security-Policy:`, `Access-Control-Allow-Origin:`, or `X-Forwarded-`. If response logging is available, look for malformed status lines, unexpected reason phrases, duplicate or attacker-controlled response headers, unexpected redirects, anomalous Set-Cookie headers, cache-control changes, or inserted test headers. For shared cache/CDN deployments, inspect cache entries and CDN logs for responses generated from suspicious CRLF-bearing requests. Because this issue requires application code to pass attacker-controlled data into the reason parameter, correlate suspicious requests with code paths that construct `aiohttp.web.Response` using `reason=`.

• %0d%0a
• %0D%0A
• %0a
• %0A
• %0d
• %0D
• \r\nSet-Cookie:
• %0d%0aSet-Cookie:
• %0D%0ASet-Cookie:
• %0d%0aLocation:
• %0D%0ALocation:
• %0d%0aCache-Control:
• %0D%0ACache-Control:
• %0d%0aContent-Security-Policy:
• %0D%0AContent-Security-Policy:
• %0d%0aAccess-Control-Allow-Origin:
• %0D%0AAccess-Control-Allow-Origin:
• %0d%0aX-Injected:
• %0D%0AX-Injected:
• %0d%0aX-Test-Injected:
• %0D%0AX-Test-Injected:
• aiohttp.web.Response(reason=

What your security team should do

• Inventory services, containers, and Python applications using AIOHTTP and identify any version older than 3.13.4.
• Prioritize patching internet-facing AIOHTTP services and applications with custom response, error handling, or middleware code.
• Upgrade to aiohttp 3.13.4 or later and rebuild dependency lockfiles and container images to prevent vulnerable versions from remaining in runtime artifacts.
• Search code for `reason=` in AIOHTTP Response creation and remove any dependency on user-controlled input for reason phrases.
• Add or tune WAF/API-gateway detections for CRLF injection attempts using `%0d%0a`, `%0a`, `%0d`, and header-name payloads in query strings, paths, and request bodies.
• Review recent access logs, WAF logs, proxy logs, and application logs for CRLF/header injection probes, especially against endpoints that return custom errors.
• If suspicious activity is found, inspect cache layers, cookies, redirect behavior, and security headers for signs of manipulation or poisoning.