CVE-2026-34520

What it actually does

AioHTTP versions before 3.13.4 accept null bytes and other control characters in HTTP response headers when using the C HTTP parser, which is the default in most installations. This is an improper input validation flaw: malformed header values that should be rejected can be parsed and handed to application code. Depending on how the application consumes, forwards, logs, caches, or enforces security decisions based on those headers, this can enable header confusion, response header injection, policy bypasses, cache poisoning, or integrity-impacting behavior in downstream components.

Why it matters to the business

Applications that use affected AioHTTP versions may incorrectly trust malformed responses from upstream services, APIs, proxies, or attacker-controlled endpoints. The most likely business risk is data or transaction integrity impact: incorrect routing, corrupted logs, poisoned cached content, bypassed response-handling logic, or unsafe propagation of malicious headers to users or dependent services. The issue is not currently listed in CISA KEV, has no known mature public exploit, and has a low EPSS score, but the high CVSS rating means internet-connected systems that consume untrusted HTTP responses should still be prioritized for patching.

How an attack unfolds

An attacker needs a path to supply an HTTP response to software using vulnerable AioHTTP client-side parsing. This can occur when an application requests attacker-controlled URLs, fetches data from third-party services, follows redirects to untrusted hosts, or communicates over a path where an attacker can tamper with traffic. The attacker returns a response containing null bytes or control characters inside header names or values. Vulnerable AioHTTP parsing accepts the malformed header instead of rejecting it. If the application then makes authorization, routing, caching, logging, proxying, or response-forwarding decisions based on those headers, the attacker can cause downstream components to interpret the response differently than the application intended, potentially injecting or corrupting headers, poisoning cached responses, or bypassing application logic.

How to fix it

Upgrade AioHTTP to version 3.13.4 or later wherever it is used. Because the issue affects the default C parser in most installations, treat all pre-3.13.4 deployments as potentially exposed unless dependency analysis proves otherwise. Rebuild and redeploy affected applications after updating direct and transitive dependencies. If immediate upgrade is not possible, reduce exposure by preventing requests to untrusted URLs, enforcing strict outbound allowlists, requiring TLS validation, disabling unsafe redirect behavior, rejecting response headers that contain ASCII control characters or null bytes before they are used, and avoiding forwarding upstream response headers directly to clients or downstream services.

How to confirm the fix worked

Confirm package versions using dependency manifests, lockfiles, SBOMs, container images, and runtime package inspection such as `pip show aiohttp`, `pip freeze`, or equivalent tooling. The installed AioHTTP version should be 3.13.4 or later. Validate deployed artifacts, not only source repositories, because vulnerable versions may remain in containers, virtual environments, serverless bundles, or vendored dependencies. As a functional check, send a controlled test response from a local test server containing a null byte or control character in a response header and verify that the application rejects the response or raises a parsing error after the upgrade. Also verify that application-level header forwarding, caching, and logging paths do not preserve or emit control characters from upstream responses.

Typical attack path

1. Identify an application or service that uses AioHTTP before version 3.13.4 to make outbound HTTP requests.
2. Find a way to influence the target application to request an attacker-controlled or attacker-influenced HTTP endpoint.
3. Return an HTTP response containing null bytes or other control characters in one or more response headers.
4. Rely on the vulnerable AioHTTP C parser accepting the malformed headers instead of rejecting the response.
5. Trigger application-specific behavior where the malformed header is logged, cached, proxied, reflected, or used in a security or routing decision.
6. Use the resulting parser mismatch or header confusion to corrupt data, poison cache entries, inject downstream headers, or bypass response-handling controls.

How to detect it

Look for evidence that an application using vulnerable AioHTTP received malformed HTTP response headers from upstream systems. Useful sources include application logs, reverse proxy logs, egress proxy logs, HTTP client debug logs, WAF or API gateway logs, packet captures, cache logs, and error monitoring telemetry. Focus on requests to unusual or attacker-controlled domains, unexpected redirects, upstream responses with non-printable characters in headers, parsing warnings, cache anomalies, and log entries containing escaped null bytes or control-character representations. If the application forwards upstream headers to clients, compare upstream response captures with downstream responses for injected, truncated, or duplicated headers. Because exploitation depends heavily on application-specific handling and there are no widely reported public exploit artifacts, absence of a fixed string does not rule out exploitation; forensic review should focus on malformed response metadata and suspicious outbound HTTP destinations during the vulnerable period.

• \x00
• %00
• \u0000
• NUL
• Invalid header
• Invalid HTTP header
• malformed header
• control character in header
• aiohttp.http_exceptions
• aiohttp.client_exceptions.ClientResponseError

What your security team should do

• Inventory all applications, containers, serverless functions, and Python environments that include AioHTTP.
• Prioritize internet-facing services, URL fetchers, webhooks, proxy-like services, crawlers, API gateways, integrations with untrusted third-party endpoints, and applications that forward or cache upstream response headers.
• Upgrade AioHTTP to 3.13.4 or later and redeploy affected workloads.
• Search dependency lockfiles and SBOMs for transitive AioHTTP usage, not only direct imports.
• Add or verify outbound request allowlisting for services that should not fetch arbitrary URLs.
• Add defensive validation that rejects null bytes and ASCII control characters in upstream response headers before logging, forwarding, caching, or making trust decisions.
• Review recent logs for malformed upstream response headers, parsing anomalies, unusual redirects, and cache entries generated from untrusted origins.
• Monitor vendor advisories for additional details because no mature exploit is currently reported, but exploitability can vary significantly by application behavior.