CVE-2025-53643

What it actually does

aiohttp versions prior to 3.12.14 can incorrectly parse HTTP requests when using the pure Python HTTP parser because trailer sections in chunked requests are not handled consistently. In deployments where aiohttp sits behind a reverse proxy, load balancer, WAF, API gateway, or firewall that parses the same request differently, this discrepancy can allow HTTP request smuggling. The vulnerable condition is most relevant when aiohttp is installed without its normal C extensions or when AIOHTTP_NO_EXTENSIONS is enabled. Successful exploitation can cause the backend aiohttp service to interpret attacker-controlled bytes as a separate or altered request, potentially bypassing routing, authentication, filtering, or request-boundary assumptions enforced upstream.

Why it matters to the business

The main business risk is that internet-facing Python services using vulnerable aiohttp configurations may be reachable in ways that bypass normal proxy or firewall protections. This can lead to unauthorized access to protected endpoints, manipulation of another user's request flow, cache poisoning, log confusion, or exposure of internal application behavior. The EPSS score is low and the issue is not listed in the CISA Known Exploited Vulnerabilities catalog, but the vulnerability has been public for more than a year, so organizations should treat remaining exposure as a hygiene and defense-in-depth gap, especially for externally exposed services behind proxies.

How an attack unfolds

An attacker targets an HTTP endpoint served by aiohttp behind an intermediary such as a reverse proxy or WAF. They send a crafted chunked HTTP request that includes trailer-related syntax or extra bytes in a way that the intermediary and the aiohttp pure Python parser disagree about where the request ends. The proxy may believe it has forwarded one complete, acceptable request, while the aiohttp backend may treat leftover bytes as the beginning of another request or parse subsequent traffic out of sync. If the application relies on the proxy for access control, normalization, routing, or filtering, the smuggled backend request may reach endpoints or code paths that should have been blocked or handled differently.

How to fix it

Upgrade aiohttp to version 3.12.14 or later. For source-based deployments, ensure the code includes fixed commit 90b6cf6f3e303309db6d388f1e53d0f30997e1c8 or a later commit containing the patch. Rebuild and redeploy application images or virtual environments so the patched package is actually in use at runtime. If immediate upgrade is not possible, reduce exposure by ensuring aiohttp C extensions are installed and active, removing AIOHTTP_NO_EXTENSIONS if it is set, blocking or normalizing ambiguous chunked requests with trailers at the edge, disabling unsupported request trailers where feasible, and placing strict request-size, header, and connection-reuse controls on front-end proxies.

How to confirm the fix worked

Confirm the runtime aiohttp version is 3.12.14 or later using package inventory, SBOM data, pip freeze, importlib.metadata, or container image inspection. Verify that no deployment path sets AIOHTTP_NO_EXTENSIONS and that aiohttp is not falling back to the pure Python parser unexpectedly. For source builds, verify the deployed code includes commit 90b6cf6f3e303309db6d388f1e53d0f30997e1c8 or later. In a controlled test environment, send chunked requests containing trailer sections through the same proxy path used in production and confirm the backend rejects, consumes, or normalizes them consistently without request desynchronization. Review reverse proxy and application logs to confirm that one client request is logged as one backend request and that no unexpected extra request is generated from trailing bytes.

Typical attack path

1. Identify an aiohttp-based HTTP service, especially one exposed through a reverse proxy, API gateway, WAF, load balancer, or firewall.
2. Determine whether the backend behavior suggests use of a vulnerable aiohttp version and the pure Python parser path, such as deployments without C extensions or with AIOHTTP_NO_EXTENSIONS enabled.
3. Send crafted chunked HTTP requests containing trailer sections or ambiguous request-boundary data.
4. Abuse parsing differences between the front-end intermediary and aiohttp backend to desynchronize the request stream.
5. Use the desynchronization to smuggle a backend request that bypasses proxy-level filtering, routing, or authentication assumptions.
6. Observe application responses, timing anomalies, unexpected status codes, or access to normally protected functionality.

How to detect it

To assess whether exploitation has already occurred, review logs from reverse proxies, WAFs, load balancers, API gateways, and aiohttp application servers for the same time windows. Look for HTTP/1.1 requests using Transfer-Encoding: chunked together with Trailer headers, malformed trailer syntax, extra bytes after the terminating zero-size chunk, or cases where the proxy records one request but the backend records two or more requests on the same connection. Pay attention to unexpected requests to admin, internal, debug, authentication, or metadata-like paths immediately after malformed chunked requests from the same source IP or connection. Investigate discrepancies between front-end and backend status codes, request IDs, methods, paths, content lengths, and connection reuse behavior. Application logs may also show parser exceptions, invalid method errors, bad request-line errors, or unexplained 400 responses followed by successful access to sensitive endpoints. Because this issue produces protocol-level desynchronization rather than a single universal payload, detection should focus on request-boundary anomalies and trailer-bearing chunked requests reaching aiohttp services.

• Transfer-Encoding: chunked
• Trailer:
• TE: trailers
• AIOHTTP_NO_EXTENSIONS
• AIOHTTP_NO_EXTENSIONS=1
• aiohttp==3.12.13
• aiohttp==3.12.12
• aiohttp==3.12.11
• aiohttp==3.12.10
• aiohttp==3.12.9
• aiohttp==3.12.8
• aiohttp==3.12.7
• aiohttp==3.12.6
• aiohttp==3.12.5
• aiohttp==3.12.4
• aiohttp==3.12.3
• aiohttp==3.12.2
• aiohttp==3.12.1
• aiohttp==3.12.0
• \r\n0\r\nTrailer:
• \r\n0\r\n\r\nGET
• \r\n0\r\n\r\nPOST
• BadStatusLine
• Invalid method encountered

What your security team should do

• Inventory Python services using aiohttp and prioritize internet-facing services or services behind reverse proxies, WAFs, API gateways, load balancers, or firewalls.
• Upgrade aiohttp to 3.12.14 or later across application code, containers, base images, and dependency lockfiles.
• Search deployment manifests, runtime environment variables, and container configurations for AIOHTTP_NO_EXTENSIONS and remove it unless explicitly required and risk-accepted.
• Validate that aiohttp C extensions are installed and functioning where aiohttp is still exposed before full remediation is complete.
• Add edge controls to reject malformed or ambiguous chunked requests with trailers when the application does not require HTTP trailers.
• Hunt historical logs for suspicious chunked requests with Trailer headers, repeated malformed HTTP parsing errors, request-boundary anomalies, or unexpected protected-endpoint access immediately following malformed requests.
• Add regression tests for HTTP request smuggling cases involving chunked bodies and trailers to prevent reintroduction during future dependency or proxy changes.