CVE-2026-34519: AIOHTTP XSS Vulnerability

CVE-2026-34519 Overview

AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. A vulnerability exists in versions prior to 3.13.4 where an attacker who controls the reason parameter when creating a Response object may be able to inject extra headers through HTTP Response Splitting. This occurs due to insufficient validation of newline and carriage return characters in the status line, enabling the injection of arbitrary HTTP headers into responses.

Critical Impact

Applications using AIOHTTP that pass untrusted input to the Response reason parameter may be vulnerable to HTTP Response Splitting attacks, potentially enabling cache poisoning, session hijacking, or cross-site scripting through injected headers.

Affected Products

• AIOHTTP versions prior to 3.13.4
• Python applications using vulnerable AIOHTTP releases
• Asyncio-based web services with user-controllable response reason parameters

Discovery Timeline

• 2026-04-01 - CVE CVE-2026-34519 published to NVD
• 2026-04-01 - Last updated in NVD database

Technical Details for CVE-2026-34519

Vulnerability Analysis

This vulnerability is classified under CWE-113 (Improper Neutralization of CRLF Sequences in HTTP Headers), commonly known as HTTP Response Splitting. The flaw exists in AIOHTTP's HTTP response serialization logic, specifically in how the status line reason phrase is processed before being written to the output buffer.

When constructing HTTP responses, the framework failed to validate that the reason parameter does not contain newline (\n) or carriage return (\r) characters. An attacker with control over this parameter could inject CRLF sequences followed by arbitrary HTTP headers, effectively splitting the response and injecting malicious content.

HTTP Response Splitting can lead to various downstream attacks including cache poisoning, where malicious responses are cached by intermediary proxies, and header injection attacks that could manipulate browser behavior through injected headers like Set-Cookie or Location.

Root Cause

The root cause lies in the _write_str function within aiohttp/_http_writer.pyx and the _py_serialize_headers function in aiohttp/http_writer.py. These functions wrote the status line directly to the output buffer without checking for embedded CRLF characters. The status line, which includes the reason phrase, was trusted to be safe for direct inclusion in the HTTP response.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker must have control over the reason parameter value passed to the AIOHTTP Response constructor. This could occur in scenarios where the application dynamically constructs response reason phrases based on user input or external data sources. By injecting CRLF sequences (\r\n) followed by additional header lines, an attacker can append arbitrary headers to the HTTP response.

    _init_writer(&writer, buf)

    try:
-        if _write_str(&writer, status_line) < 0:
+        if _write_str_raise_on_nlcr(&writer, status_line) < 0:
             raise
        if _write_byte(&writer, b'\r') < 0:
             raise

Source: GitHub Commit Change

The patch introduces a new function _write_str_raise_on_nlcr that validates the status line does not contain newline or carriage return characters before writing, raising an exception if invalid characters are detected.

def _py_serialize_headers(status_line: str, headers: "CIMultiDict[str]") -> bytes:
+    _safe_header(status_line)
    headers_gen = (_safe_header(k) + ": " + _safe_header(v) for k, v in headers.items())
    line = status_line + "\r\n" + "\r\n".join(headers_gen) + "\r\n\r\n"
    return line.encode("utf-8")

Source: GitHub Commit Change

The Python implementation now applies _safe_header validation to the status line, ensuring CRLF characters are properly rejected.

Detection Methods for CVE-2026-34519

Indicators of Compromise

• HTTP responses containing unexpected headers not set by the application
• Log entries showing reason phrases with encoded or unusual characters (%0d, %0a, \r, \n)
• Cache entries with suspicious or malformed HTTP responses
• Reports of session hijacking or unexpected cookie behavior from users

Detection Strategies

• Implement Web Application Firewall (WAF) rules to detect CRLF sequences in request parameters that may influence response construction
• Monitor application logs for errors related to malformed HTTP responses or header serialization failures
• Use static analysis tools to identify code paths where user input reaches the Response reason parameter
• Deploy runtime application self-protection (RASP) to detect and block HTTP response splitting attempts

Monitoring Recommendations

• Enable verbose logging on HTTP response generation to capture reason phrase values
• Monitor for anomalous HTTP response sizes that may indicate injected headers
• Set up alerts for repeated serialization errors in AIOHTTP-based applications
• Review dependency management tools for alerts on vulnerable AIOHTTP versions

How to Mitigate CVE-2026-34519

Immediate Actions Required

• Upgrade AIOHTTP to version 3.13.4 or later immediately
• Audit application code for any instances where user input is passed to Response reason parameters
• Implement input validation to strip or reject CRLF characters from any values that may reach the Response constructor
• Review cached responses for potential poisoning if exploitation is suspected

Patch Information

The vulnerability has been patched in AIOHTTP version 3.13.4. The fix introduces validation functions that reject status lines containing newline or carriage return characters. The patch modifies both the Cython implementation (_http_writer.pyx) and the pure Python fallback (http_writer.py) to ensure consistent protection.

For detailed patch information, see the GitHub Security Advisory GHSA-mwh4-6h8g-pg8w and the release notes for v3.13.4.

Workarounds

• Sanitize all input that may be used in Response reason phrases by removing \r and \n characters
• Use a hardcoded reason phrase instead of dynamic values derived from user input
• Implement a middleware layer that validates response headers before transmission
• Deploy a reverse proxy with header validation capabilities in front of the application

# Upgrade AIOHTTP to patched version
pip install --upgrade aiohttp>=3.13.4

# Verify installed version
pip show aiohttp | grep Version

# For requirements.txt, update the constraint
echo "aiohttp>=3.13.4" >> requirements.txt