CVE-2026-34517: AIOHTTP DoS Vulnerability

CVE-2026-34517 Overview

CVE-2026-34517 is a Resource Exhaustion vulnerability affecting AIOHTTP, an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, the framework contained a flaw in its multipart form field handling where certain form fields were read entirely into memory before checking the client_max_size limit. This improper resource allocation could allow attackers to consume excessive server memory by sending crafted multipart requests.

Critical Impact

Attackers can bypass the client_max_size protection mechanism to cause memory exhaustion on servers handling multipart form data, potentially leading to denial of service conditions.

Affected Products

• AIOHTTP versions prior to 3.13.4
• Python applications using AIOHTTP for multipart form handling
• Web servers and APIs built on the AIOHTTP framework

Discovery Timeline

• 2026-04-01 - CVE CVE-2026-34517 published to NVD
• 2026-04-01 - Last updated in NVD database

Technical Details for CVE-2026-34517

Vulnerability Analysis

This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The core issue lies in the order of operations within AIOHTTP's multipart form processing logic. When handling ordinary (non-file) form fields, the framework's web_request.py module would call field.read(decode=True) to read the entire field content into memory before performing the size validation against max_size. This design flaw created a window where an attacker could submit arbitrarily large form field data that would be fully loaded into memory before the framework could reject it for exceeding size limits.

The vulnerability is exploitable over the network without authentication, though the impact is limited to availability degradation. Applications that accept multipart form data from untrusted sources are particularly susceptible to this memory exhaustion attack.

Root Cause

The root cause is improper placement of the size validation check in the multipart form processing pipeline. The original code accumulated the entire field value in memory using await field.read(decode=True), then calculated the size and performed the validation afterward. This approach defeats the purpose of the client_max_size configuration, as malicious payloads have already consumed memory by the time the check occurs.

Attack Vector

An attacker can exploit this vulnerability by sending HTTP requests with multipart form data containing oversized non-file fields. Since the size check occurs after the data is read into memory, the attacker can craft requests with field values significantly larger than the configured max_size limit. By sending multiple such requests, an attacker could exhaust available server memory, causing degraded performance or complete service unavailability.

                         out.add(field.name, ff)
                     else:
                         # deal with ordinary data
-                        value = await field.read(decode=True)
+                        raw_data = bytearray()
+                        while chunk := await field.read_chunk():
+                            size += len(chunk)
+                            if 0 < max_size < size:
+                                raise HTTPRequestEntityTooLarge(
+                                    max_size=max_size, actual_size=size
+                                )
+                            raw_data.extend(chunk)
+
+                        value = bytearray()
+                        # form-data doesn't support compression, so don't need to check size again.
+                        async for d in field.decode_iter(raw_data):
+                            value.extend(d)
+
                         if field_ct is None or field_ct.startswith("text/"):
                             charset = field.get_charset(default="utf-8")
                             out.add(field.name, value.decode(charset))
                         else:
                             out.add(field.name, value)
-                        size += len(value)
-                        if 0 < max_size < size:
-                            raise HTTPRequestEntityTooLarge(
-                                max_size=max_size, actual_size=size
-                            )
                 else:
                     raise ValueError(

Source: GitHub Commit Details

The patch modifies the code to read form field data in chunks using field.read_chunk(), validating the accumulated size after each chunk. This ensures that the HTTPRequestEntityTooLarge exception is raised before excessive memory is allocated.

Detection Methods for CVE-2026-34517

Indicators of Compromise

• Unusual memory consumption spikes on servers running AIOHTTP applications
• HTTP 413 (Request Entity Too Large) errors occurring after significant memory allocation
• Abnormally large multipart form submissions in web server access logs
• Application crashes or out-of-memory errors coinciding with multipart form requests

Detection Strategies

• Monitor application memory usage patterns and alert on sudden spikes during form processing
• Implement request logging that captures multipart form field sizes before processing
• Deploy application performance monitoring (APM) tools to track memory allocation in AIOHTTP request handlers
• Review web application firewall (WAF) logs for unusually large POST requests with multipart content types

Monitoring Recommendations

• Configure memory usage thresholds and alerts for AIOHTTP worker processes
• Implement rate limiting on endpoints that accept multipart form data
• Enable detailed request logging including Content-Length headers for multipart submissions
• Use SentinelOne Singularity Platform to monitor for resource exhaustion patterns and anomalous application behavior

How to Mitigate CVE-2026-34517

Immediate Actions Required

• Upgrade AIOHTTP to version 3.13.4 or later immediately
• Review application configurations for client_max_size settings and ensure they are appropriately restrictive
• Implement request size validation at the reverse proxy or load balancer level as defense-in-depth
• Monitor server memory utilization for signs of ongoing exploitation attempts

Patch Information

The vulnerability has been addressed in AIOHTTP version 3.13.4. The fix (commit cbb774f38330563422ca0c413a71021d7b944145) changes the multipart form field reading logic to validate size incrementally during chunk-based reading rather than after loading the entire field into memory.

For detailed patch information, refer to:

• GitHub Release v3.13.4
• GitHub Security Advisory GHSA-3wq7-rqq7-wx6j

Workarounds

• Implement strict request size limits at the web server or reverse proxy level (e.g., nginx client_max_body_size)
• Deploy rate limiting on endpoints that accept multipart form data to reduce exploitation impact
• Consider implementing memory limits for AIOHTTP worker processes using container resource constraints or system limits
• Monitor and restart processes that exceed memory thresholds as a temporary mitigation

# Configuration example - nginx upstream protection
# Add to nginx server configuration to enforce size limits before reaching AIOHTTP
client_max_body_size 10M;

# Or use ulimit to constrain AIOHTTP process memory
ulimit -v 1048576  # Limit virtual memory to 1GB
python -m aiohttp.web your_app:app