CVE-2026-42561: Python-Multipart DoS Vulnerability

CVE-2026-42561 Overview

CVE-2026-42561 is a denial of service vulnerability in python-multipart, a streaming multipart parser used by Python web frameworks including Starlette and FastAPI. The flaw exists in the MultipartParser component prior to version 0.0.27. The parser places no limit on either the number of part headers or the size of an individual part header when processing multipart/form-data requests. Remote attackers can submit crafted requests containing many repeated headers without terminating the header block, or a single oversized header value. The server consumes excessive CPU cycles parsing these inputs before the request is rejected or completed. The issue is tracked under [CWE-770: Allocation of Resources Without Limits or Throttling].

Critical Impact

Unauthenticated remote attackers can exhaust CPU resources on any service that ingests multipart form data, degrading availability for legitimate users.

Affected Products

• python-multipart versions prior to 0.0.27
• Python web applications and frameworks that depend on python-multipart for form parsing (including Starlette and FastAPI deployments)
• Any HTTP endpoint accepting multipart/form-data content through the affected parser

Discovery Timeline

• 2026-05-13 - CVE-2026-42561 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-42561

Vulnerability Analysis

The MultipartParser class streams multipart/form-data payloads and parses part headers as bytes arrive on the wire. The parser accumulates header name and value bytes into internal buffers and continues processing until it encounters the header terminator sequence. Because no upper bound is enforced on the header count or the per-header byte length, an attacker controls both dimensions of the parsing work.

When a request contains thousands of repeated part headers without a terminating empty line, the parser performs work proportional to the input size before any application-level handler runs. A similar effect occurs when a single header value spans many kilobytes or megabytes. The CPU time spent inside the parsing loop blocks the worker thread or async task handling the request.

In typical deployments behind a WSGI or ASGI server, each malicious request occupies a worker until parsing completes or fails. A small number of concurrent attackers can saturate the available worker pool, producing a denial of service against the entire application.

Root Cause

The root cause is missing input validation on parser state transitions. MultipartParser lacks both a maximum part header count and a maximum header line length. Streaming parsers must enforce hard ceilings on accumulator buffers to bound worst-case work per request. Version 0.0.27 introduces these limits and rejects oversized header blocks early.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker sends an HTTP POST or PUT request with Content-Type: multipart/form-data to any endpoint that invokes the vulnerable parser. The malicious payload contains either an unbounded sequence of repeated part headers or a single header field with an oversized value. Refer to the GitHub Security Advisory GHSA-pp6c-gr5w-3c5g for the upstream technical description.

Detection Methods for CVE-2026-42561

Indicators of Compromise

• HTTP requests with Content-Type: multipart/form-data and abnormally large Content-Length values that contain few or no file parts
• Request bodies where individual part header lines exceed several kilobytes
• Repeated identical part header names within a single multipart boundary section without a terminating empty line
• Sustained elevation in application worker CPU utilization correlated with multipart upload endpoints

Detection Strategies

• Inspect web server and reverse proxy access logs for multipart/form-data requests with unusual size-to-completion-time ratios
• Deploy WAF rules that cap the number of headers per multipart part and the byte length of any single header line
• Monitor application performance metrics for spikes in p95 and p99 request latency on upload endpoints

Monitoring Recommendations

• Track CPU utilization per worker process and alert when sustained utilization exceeds normal baselines on endpoints that accept file uploads
• Log and review HTTP 400 and 413 response rates from multipart endpoints for anomalies
• Capture the dependency version of python-multipart in software bill of materials (SBOM) inventories and alert on versions below 0.0.27

How to Mitigate CVE-2026-42561

Immediate Actions Required

• Upgrade python-multipart to version 0.0.27 or later across all Python services
• Audit transitive dependencies in Starlette, FastAPI, and other frameworks to confirm the patched version is resolved
• Apply request size and rate limits at the reverse proxy or WAF layer in front of affected applications

Patch Information

The maintainers fixed the issue in python-multipart0.0.27 by enforcing limits on the number of part headers and on individual header line size. See the GitHub Security Advisory GHSA-pp6c-gr5w-3c5g for upstream details.

Workarounds

• Configure an upstream reverse proxy such as nginx or Envoy to enforce a maximum request body size on multipart endpoints
• Restrict header size limits at the load balancer to reject requests with oversized header lines before they reach application workers
• Apply per-IP request rate limiting to upload routes to reduce the impact of concurrent abusive clients

# Configuration example: upgrade python-multipart to the patched release
pip install --upgrade 'python-multipart>=0.0.27'

# Verify the installed version
python -c "import multipart; print(multipart.__version__)"