CVE-2026-34517

What it actually does

Prior to aiohttp 3.13.4, certain multipart form fields are fully read into process memory before aiohttp enforces the configured client_max_size limit. A remote unauthenticated client can send specially structured multipart/form-data requests with oversized fields that bypass early size enforcement, causing excessive memory consumption in the Python worker process. The primary impact is availability degradation: worker crashes, out-of-memory termination, request handling stalls, or service instability. There is no indicated confidentiality or integrity impact.

Why it matters to the business

Applications or APIs built on vulnerable aiohttp versions may be disrupted by relatively simple network requests, especially services that accept file uploads, form submissions, webhooks, or multipart API traffic. Successful exploitation can cause service outages, degraded performance, failed customer transactions, autoscaling cost increases, and operational incident response load. The CVSS score is moderate and EPSS is currently low, with no KEV listing or known ransomware association, but internet-facing upload endpoints should still be prioritized because exploitation requires no authentication or user interaction.

How an attack unfolds

An attacker identifies an aiohttp-based HTTP service that accepts multipart/form-data requests. They send one or more POST or PUT requests containing multipart fields crafted so that aiohttp reads the field content into memory before applying client_max_size. By making the field sufficiently large, or by repeating requests concurrently, the attacker forces the application process to allocate excessive memory. Depending on deployment limits, the process may slow down, raise MemoryError exceptions, be killed by the operating system or container runtime, or become unavailable behind a load balancer. The attacker does not need credentials and does not need to exploit code execution; the attack goal is resource exhaustion and denial of service.

How to fix it

Upgrade aiohttp to version 3.13.4 or later wherever it is used, including direct dependencies and transitive dependencies bundled into applications or container images. Rebuild and redeploy affected services after upgrading; restarting without rebuilding may leave vulnerable packages in place. If immediate upgrade is not possible, reduce exposure by placing strict request-body limits at a reverse proxy, API gateway, WAF, or ingress controller before traffic reaches aiohttp; disable or restrict multipart upload endpoints where feasible; require authentication for upload routes; rate-limit large POST/PUT requests; and set conservative memory limits with health checks and automatic restart policies. These mitigations reduce impact but should not be treated as a substitute for upgrading.

How to confirm the fix worked

Confirm the installed aiohttp version is 3.13.4 or later in every runtime image and virtual environment using package inventory, lockfiles, SBOMs, or commands such as `python -m pip show aiohttp` and `python -c "import aiohttp; print(aiohttp.__version__)"`. Verify deployed containers or hosts are running the rebuilt artifact, not only that source manifests were updated. Review dependency lockfiles for transitive aiohttp pins below 3.13.4. For exposure validation, identify aiohttp services with multipart/form-data endpoints and confirm upstream body-size limits are enforced before requests reach the Python application. Where safe, perform controlled testing in a non-production environment with oversized multipart requests and confirm the service rejects them without abnormal memory growth.

Typical attack path

1. Discover an aiohttp-backed endpoint that accepts multipart/form-data, such as upload, form submission, or API ingestion routes.
2. Send a multipart request with an oversized field type affected by the vulnerable parsing path.
3. Cause aiohttp to buffer the field in memory before client_max_size is enforced.
4. Repeat the request or run requests concurrently to amplify memory pressure.
5. Trigger worker slowdown, application errors, container restarts, operating-system OOM kills, or service unavailability.

How to detect it

To determine whether this was already exploited, correlate HTTP access logs, application logs, container/runtime events, host kernel logs, and monitoring telemetry for aiohttp services. Focus on periods with memory spikes, worker restarts, container OOM kills, increased latency, elevated 5xx responses, or sudden 413/400 responses involving multipart/form-data requests. Review access logs for unauthenticated or unusual clients sending large POST or PUT requests to upload, form, import, webhook, or ingestion endpoints. In application logs, look for MemoryError, asyncio/aiohttp request-body parsing exceptions, HTTPRequestEntityTooLarge, abrupt connection resets, and worker termination messages. In Kubernetes or container platforms, review pod restart reasons such as OOMKilled and correlate them with preceding multipart requests from the same source IPs or user agents. There are no public threat actors or KEV exploitation reports associated with this vulnerability in the provided data, so detection should emphasize behavioral evidence of resource-exhaustion attempts rather than fixed malware artifacts.

• Content-Type: multipart/form-data
• multipart/form-data; boundary=
• aiohttp.web_exceptions.HTTPRequestEntityTooLarge
• HTTPRequestEntityTooLarge
• Request Entity Too Large
• Payload Too Large
• client intended to send too large body
• MemoryError
• Out of memory: Killed process
• OOMKilled
• Killed process
• exceeded memory limit
• POST
• PUT

What your security team should do

• Inventory all Python applications, containers, and serverless functions that include aiohttp, prioritizing internet-facing services and endpoints that accept multipart/form-data.
• Upgrade aiohttp to 3.13.4 or later, rebuild artifacts, redeploy, and verify the runtime package version.
• Add or confirm request-size limits at reverse proxies, ingress controllers, API gateways, and WAFs so oversized multipart requests are rejected before reaching aiohttp.
• Apply rate limiting and authentication controls to upload and form-submission endpoints, especially unauthenticated public routes.
• Monitor memory usage, worker restarts, HTTP 413 responses, 5xx spikes, and OOM kill events for services using aiohttp.
• Search historical logs for unusually large or repeated multipart POST/PUT requests followed by memory errors, process restarts, or availability incidents.
• Add dependency scanning or SBOM policy checks that fail builds containing aiohttp versions earlier than 3.13.4.