CVE-2026-34525: 
Wolfi vulnerability analysis and mitigation

CVE-2026-34525 is a duplicate Host header acceptance vulnerability in the aiohttp asynchronous HTTP client/server framework for Python. Prior to version 3.13.4, aiohttp failed to reject HTTP requests containing multiple Host headers, violating RFC 9110 singleton header requirements. This affects all aiohttp versions up to and including 3.13.3. It was disclosed on April 1, 2026, with a CVSS v3.1 score of 5.3 (Medium) and a CVSS v4.0 score of 6.3 (Medium) (Github Advisory, aiohttp Security Advisory).

The root cause is improper input validation (CWE-20) in aiohttp's HTTP request parser — both the C extension (_http_parser.pyx) and the pure Python (http_parser.py) implementations — which failed to enforce RFC 9110's requirement that certain headers (including Host) appear only once per request. This is classified as an HTTP Request Smuggling issue (CWE-444) because the discrepancy between how a front-end reverse proxy and aiohttp interpret duplicate Host headers can be exploited. Specifically, if a reverse proxy applies access control rules based on the Host header value, an attacker could send a request with two Host headers — one that satisfies the proxy's security check and one targeting a privileged sub-application registered via Application.add_domain() — causing the proxy and aiohttp to route the request differently. The fix, applied in commits e00ca3c and 53e2e6f, adds per-header singleton enforcement during parsing in strict mode (request parsing), raising a BadHttpMessage exception on duplicate detection (aiohttp Security Advisory, Commit e00ca3c, Commit 53e2e6f).

The primary risk is security control bypass in deployments where a reverse proxy enforces host-based access rules in front of an aiohttp application using Application.add_domain(). An attacker could craft a request with two Host headers — one passing the proxy's filter and one targeting a privileged domain — potentially gaining unauthorized access to restricted sub-applications. There is no direct confidentiality or availability impact to aiohttp itself; the integrity impact is limited to unauthorized request routing. The vulnerability does not affect deployments that do not use host-based routing or Application.add_domain() (aiohttp Security Advisory, Github Advisory).

No public proof-of-concept exploit code has been observed, and there is no evidence of in-the-wild exploitation at this time (Github Advisory). The EPSS score is approximately 0.085–0.139%, placing it in the 34th percentile for exploitation likelihood within 30 days. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires a specific deployment configuration (reverse proxy + aiohttp with Application.add_domain()), which limits the practical attack surface.

1. Reconnaissance: Identify a target application using aiohttp (version ≤ 3.13.3) behind a reverse proxy that enforces host-based access control rules, and that uses Application.add_domain() to register privileged sub-applications.
2. Identify target domains: Determine the public-facing hostname accepted by the proxy and the internal/privileged hostname registered with Application.add_domain() in aiohttp.
3. Craft a dual-Host request: Construct an HTTP request containing two Host headers — the first matching the proxy's allowed hostname, and the second targeting the privileged aiohttp sub-application domain:

GET /admin HTTP/1.1
Host: public.example.com
Host: admin.internal.example.com

4. Send the request: Transmit the crafted request to the reverse proxy. The proxy evaluates only the first (or last, depending on implementation) Host header and permits the request.
5. Achieve bypass: aiohttp, prior to the fix, accepts both headers and may route the request to the privileged sub-application associated with the second Host value, bypassing the proxy's security check (aiohttp Security Advisory).

• Network: HTTP requests to aiohttp-backed services containing multiple Host headers (e.g., Host: public.example.com followed by Host: admin.internal.example.com) in a single request.
• Logs: Access log entries showing requests to privileged or internal paths (e.g., /admin, /internal) originating from unexpected source IPs or with anomalous Host header values; reverse proxy logs showing a permitted request that aiohttp routed to a restricted sub-application.
• Application Behavior: Unexpected access to routes registered under Application.add_domain() for internal or privileged domains from external clients.

Upgrade aiohttp to version 3.13.4 or later, which rejects duplicate singleton headers (including Host) during request parsing in both the C extension and pure Python parsers (aiohttp Release v3.13.4, Github Advisory). If immediate patching is not possible, implement input validation at the reverse proxy layer to reject or normalize requests containing multiple Host headers before they reach aiohttp. Applications not using Application.add_domain() or host-based routing are at significantly reduced risk. IBM products including Process Mining, API Connect, watsonx Code Assistant On Prem, and Instana Observability have also released interim fixes addressing this CVE (IBM Process Mining Fix, IBM API Connect).

The vulnerability was reported by security researcher 5yu4n and remediated by rodrigobnogueira and bdraco from the aiohttp maintainer team (aiohttp Security Advisory). The advisory notes the impact is limited and primarily theoretical, affecting only specific deployment configurations. Downstream vendors including IBM have issued security bulletins addressing the CVE in their products. The Debian LTS team also issued an update for the affected package.