CVE-2026-34516

What it actually does

AIOHTTP versions prior to 3.13.4 can consume excessive memory when processing multipart HTTP responses containing an unusually large number of headers. The flaw is a network-reachable denial-of-service condition: an unauthenticated attacker can cause a vulnerable AIOHTTP-based client or server component to allocate more memory than intended, potentially leading to process slowdown, worker crashes, container restarts, or service unavailability. The vulnerability affects availability only; it does not directly provide code execution, authentication bypass, or data disclosure.

Why it matters to the business

Services that use vulnerable AIOHTTP multipart parsing can be made unstable or unavailable by crafted HTTP traffic or crafted upstream responses. This can disrupt APIs, background integrations, webhooks, file upload workflows, async microservices, and Python services that depend on AIOHTTP. Although the EPSS score is currently low and there is no known CISA KEV listing or public exploit maturity reported, the low attack complexity and no-authentication requirement make remediation important for internet-facing or high-availability services.

How an attack unfolds

An attacker identifies an application, API endpoint, proxy workflow, webhook consumer, or integration path that uses a vulnerable AIOHTTP version to process multipart content. The attacker then sends, or causes the application to retrieve, an HTTP multipart message with an excessive number of part headers. During parsing, AIOHTTP allocates memory beyond intended limits. Repeated or concurrent requests can exhaust process or host memory, trigger garbage collection pressure, crash workers, cause container restarts, or make the service stop responding. In client-side usage, exploitation may occur if a vulnerable service fetches attacker-controlled or compromised upstream content and parses a malicious multipart response.

How to fix it

Upgrade AIOHTTP to version 3.13.4 or later wherever it is used. For Python deployments, update dependency manifests and lockfiles, rebuild application images, and redeploy affected services. If immediate upgrade is not possible, reduce exposure by limiting access to endpoints that parse multipart data, enforcing request size and header-count limits at reverse proxies or application gateways, applying rate limits, setting conservative process/container memory limits with safe restart behavior, and blocking untrusted upstream sources where AIOHTTP clients parse multipart responses. Treat mitigations as temporary; the durable fix is upgrading to a patched AIOHTTP release.

How to confirm the fix worked

Confirm all deployed Python environments, containers, virtual environments, and dependency lockfiles use aiohttp version 3.13.4 or later. Validate with package inventory tools such as `pip show aiohttp`, `pip freeze`, Poetry/Pipenv lockfile review, SBOM scans, and container image scans. Exercise representative multipart upload, webhook, and HTTP client workflows after upgrade to confirm compatibility. For exposure testing, review routing and application code for multipart parsing paths and ensure reverse proxies or gateways enforce request body, header, and rate limits. Do not rely only on top-level application package versions; AIOHTTP may be present as a transitive dependency.

Typical attack path

1. Discover an internet-facing service, API, webhook handler, upload endpoint, or backend integration using AIOHTTP before version 3.13.4.
2. Identify a request path or upstream-fetch workflow that causes multipart content to be parsed by AIOHTTP.
3. Send or host a crafted multipart HTTP message containing an excessive number of headers.
4. Cause the vulnerable process to allocate excessive memory while parsing the multipart content.
5. Repeat requests or increase concurrency to degrade performance, crash workers, or trigger service restarts.
6. Sustain traffic long enough to create service disruption or availability impact.

How to detect it

Look for evidence of attempted or successful denial of service rather than compromise artifacts. Useful sources include reverse proxy logs, application access logs, AIOHTTP application logs, container orchestration events, process supervisor logs, kernel OOM logs, APM telemetry, and cloud load balancer metrics. Hunt for bursts of POST, PUT, PATCH, or webhook requests with `multipart/form-data` content types, unusually large header counts, abnormal request sizes, repeated 400/413/500/502/503/504 responses, increased latency, worker exits, container restarts, and out-of-memory kills. For client-side exposure, inspect egress logs and application logs for repeated fetches of multipart responses from unfamiliar or attacker-controlled hosts followed by memory spikes or process crashes. Because this is a resource-exhaustion flaw, there may be no persistent files, registry keys, or stable malware indicators; correlate traffic anomalies with memory exhaustion and restart events.

• Content-Type: multipart/form-data
• Content-Type: multipart/
• boundary=
• MemoryError
• Out of memory
• OOMKilled
• Killed process
• container killed due to memory limit
• worker exited
• worker timeout
• upstream prematurely closed connection
• HTTP/1.1" 500
• HTTP/1.1" 502
• HTTP/1.1" 503
• HTTP/1.1" 504
• aiohttp
• aiohttp.multipart

What your security team should do

• Prioritize upgrading internet-facing, API, webhook, upload, and integration services using aiohttp before 3.13.4.
• Generate an inventory of Python services and container images containing the aiohttp package, including transitive dependencies.
• Update dependency manifests and lockfiles, rebuild artifacts, and verify runtime package versions after deployment.
• Apply temporary ingress controls for multipart requests: request body limits, header limits, rate limits, and authentication where feasible.
• Monitor memory consumption, worker restarts, HTTP 5xx spikes, and abnormal multipart request patterns until all affected services are patched.
• Review outbound HTTP client workflows that parse untrusted multipart responses, not only inbound server endpoints.
• Add dependency scanning policy checks to prevent reintroduction of aiohttp versions earlier than 3.13.4.