CVE-2026-22815

What it actually does

Prior to aiohttp 3.13.4, the framework does not sufficiently bound memory consumption while processing HTTP headers and/or trailers. A remote unauthenticated client can send specially crafted requests or responses with excessive, malformed, or continuously supplied header/trailer data that causes the aiohttp process to allocate unbounded memory. The primary impact is denial of service through memory exhaustion, process termination, container eviction, worker crashes, or degraded service availability.

Why it matters to the business

Internet-facing services built on vulnerable aiohttp versions may be taken offline or made unreliable by a low-complexity remote request pattern that does not require authentication. This can cause customer-facing outages, failed API calls, autoscaling cost spikes, degraded dependent services, and operational incident response workload. Although EPSS is currently low and there is no CISA KEV listing or known ransomware association, the vulnerability is simple to trigger over the network and affects a common Python web framework, so exposed services should still be upgraded promptly.

How an attack unfolds

An attacker first identifies a service that uses a vulnerable aiohttp version as an HTTP server or a component that consumes attacker-controlled HTTP responses. The attacker then opens one or more HTTP connections and sends requests or responses containing header or trailer sections designed to force excessive memory allocation. Because the vulnerable header/trailer handling lacks sufficient limits, memory usage grows disproportionately. Repeating the request pattern or maintaining concurrent connections can exhaust available memory, causing aiohttp workers, Python processes, containers, or hosting nodes to become slow, crash, or be restarted by supervisors. The attacker does not need credentials or user interaction; availability is the main target.

How to fix it

Upgrade aiohttp to version 3.13.4 or later wherever it is used, including direct and transitive Python dependencies. Rebuild and redeploy affected applications after updating lockfiles and container images. If immediate upgrade is not possible, reduce exposure by placing vulnerable services behind a reverse proxy or load balancer that enforces strict limits on maximum header size, number of headers, request body/trailer behavior, connection duration, and concurrent connections. Apply request-rate limiting, connection timeouts, memory limits, and automatic restart policies as compensating controls. Ensure outbound HTTP clients using aiohttp do not consume untrusted upstream responses without protective limits where applicable.

How to confirm the fix worked

Confirm dependency resolution shows aiohttp 3.13.4 or later in all deployed artifacts, virtual environments, lockfiles, SBOMs, and container images. Validate at runtime with package inventory commands such as `python -m pip show aiohttp` or equivalent environment-specific package inspection. Exercise HTTP endpoints through a staging environment with oversized-header and trailer-limit tests to verify requests are rejected by the application, reverse proxy, or upgraded framework without abnormal memory growth. Monitor process resident memory during validation and confirm no worker crash, OOM kill, or container eviction occurs.

Typical attack path

1. Discover an HTTP endpoint or integration backed by aiohttp prior to version 3.13.4.
2. Send crafted HTTP traffic with oversized, numerous, malformed, or streaming header/trailer fields.
3. Maintain or repeat connections to amplify memory allocation in the aiohttp process.
4. Exhaust process, container, or host memory.
5. Cause service latency, failed requests, worker restarts, container evictions, or full service outage.

How to detect it

Look for signs of availability-focused exploitation rather than code execution. Review reverse proxy, load balancer, WAF, application, and container orchestration logs for bursts of requests with unusually large headers, unusually high header counts, trailer-related behavior, long-lived connections, repeated malformed HTTP parsing errors, spikes in 400/431/502/503/504 responses, and many connections from the same source or distributed sources followed by memory exhaustion. Correlate these events with Python/aiohttp process memory growth, worker crashes, supervisor restarts, kernel OOM killer messages, Kubernetes OOMKilled events, container restarts, and service latency spikes. Since no specific public exploit string is provided, detection should focus on anomalous HTTP metadata volume and resource-exhaustion artifacts around vulnerable aiohttp services.

• aiohttp<3.13.4
• aiohttp 3.13.3
• aiohttp 3.13.2
• aiohttp 3.13.1
• aiohttp 3.13.0
• aiohttp 3.12.
• aiohttp 3.11.
• aiohttp 3.10.
• aiohttp 3.9.
• OOMKilled
• Killed process
• Out of memory
• MemoryError
• worker exited
• worker restart
• upstream sent too big header
• client sent too large header
• request header too large
• 431 Request Header Fields Too Large
• HTTP trailers
• Transfer-Encoding: chunked
• Trailer:

What your security team should do

• Inventory all applications, containers, serverless functions, and Python services that include aiohttp, including transitive dependencies.
• Prioritize upgrade of internet-facing or unauthenticated aiohttp services to aiohttp 3.13.4 or later.
• Add or verify reverse proxy limits for request header size, number of headers, connection duration, concurrent connections, and request rate.
• Set resource limits and alerts for abnormal Python process memory growth, worker restarts, container OOM kills, and elevated 4xx/5xx rates.
• Review dependency lockfiles and CI/CD policies to prevent deployment of aiohttp versions earlier than 3.13.4.
• If upgrade must be delayed, restrict exposure with network controls and WAF/proxy rules that reject unusually large or numerous headers and unsupported trailer usage.