CVE-2026-42561

What it actually does

This vulnerability is a network-reachable denial-of-service flaw in python-multipart versions prior to 0.0.27. During parsing of multipart/form-data requests, the MultipartParser did not enforce limits on the number of headers in each part or the maximum size of an individual part header. An unauthenticated attacker can send crafted multipart upload requests containing many repeated headers, an unterminated header block, or an extremely large header value. The application may spend excessive CPU time parsing and rejecting the request, tying up worker processes or event-loop capacity and reducing availability. The vulnerability does not provide code execution, data disclosure, or privilege escalation, but it can exhaust application resources through low-complexity remote requests.

Why it matters to the business

Applications that accept file uploads, form submissions, API requests, or webhooks using python-multipart may become slow or unavailable if exposed to crafted multipart requests. This can disrupt customer-facing services, internal portals, API integrations, and background processing pipelines that depend on affected web applications. The CVSS score indicates high availability impact, but current EPSS is low, it is not listed in CISA KEV, and no public exploit maturity is reported, so urgency should be driven by whether the package is internet-facing or used on critical upload endpoints.

How an attack unfolds

An attacker identifies a Python web application endpoint that accepts multipart/form-data, commonly file upload or form submission routes. They send HTTP POST requests with a multipart body where one part contains either a very large header value, a large number of repeated headers, or a header section that is intentionally not terminated promptly. Because vulnerable versions of python-multipart lack appropriate per-part header count and header size limits, the parser continues processing the malformed or oversized header content and performs excessive CPU work before rejecting the request or completing parsing. By repeating these requests or sending them concurrently, the attacker can occupy application workers, increase latency, and potentially make the service unavailable to legitimate users.

How to fix it

Upgrade python-multipart to version 0.0.27 or later wherever it is used directly or transitively. Review dependency lockfiles and container images to ensure the runtime package version is actually updated, not only the top-level manifest. If immediate upgrade is not possible, place compensating controls at the edge: enforce maximum request body size, maximum header size, request timeout, upload timeout, and rate limits on multipart/form-data endpoints using a reverse proxy, API gateway, WAF, or application server. Consider disabling or restricting unauthenticated upload endpoints until patched. For Python services, rebuild and redeploy artifacts after dependency updates so the fixed package is included in production images and virtual environments.

How to confirm the fix worked

Confirm the installed python-multipart version is 0.0.27 or later in every deployed artifact, virtual environment, and container image. Use dependency inspection commands such as `python -m pip show python-multipart`, `python -m pip freeze | grep -i '^python-multipart=='`, or software composition analysis results to verify the effective runtime version. Test exposed multipart endpoints with normal uploads to ensure functionality still works after upgrade. Where compensating controls are applied, verify that oversized multipart headers, excessive per-part headers, slow uploads, and large request bodies are rejected quickly at the proxy or application layer without consuming significant application CPU. Review CI/CD dependency lockfiles to ensure vulnerable versions cannot be reintroduced.

Typical attack path

1. Discover or guess an HTTP endpoint that accepts multipart/form-data, such as file upload, profile image upload, document import, or form submission functionality.
2. Send a crafted POST request with Content-Type: multipart/form-data and a valid-looking boundary.
3. Construct one multipart part with either many repeated headers, an excessively large header value, or a header block that is not terminated in a normal way.
4. Cause the vulnerable MultipartParser to consume excessive CPU while processing part headers before the request is rejected or completed.
5. Repeat the request or run many concurrent requests to exhaust application worker capacity and degrade or deny service.

How to detect it

Look for signs of resource-exhaustion activity against endpoints that accept multipart/form-data. Relevant log sources include reverse proxy logs, load balancer logs, WAF/API gateway logs, application access logs, application error logs, APM traces, container metrics, and host CPU metrics. Hunt for bursts of POST requests with `Content-Type: multipart/form-data`, unusually large request sizes, long request durations, client disconnects, gateway timeouts, 408/413/429/499/500/502/503/504 responses, or repeated failures on upload/form endpoints. Application logs may show multipart parsing errors, malformed header handling, request timeout errors, or worker timeout/restart events around CPU spikes. Because this is a denial-of-service issue rather than a compromise primitive, successful exploitation is more likely to appear as availability degradation and resource saturation than persistent files, new processes, credential access, or lateral movement artifacts.

• Content-Type: multipart/form-data
• python-multipart
• MultipartParser
• multipart parse error
• multipart/form-data
• boundary=
• POST
• HTTP 413
• HTTP 429
• HTTP 499
• HTTP 502
• HTTP 503
• HTTP 504
• upstream timed out
• request body too large
• client intended to send too large body
• worker timeout
• WORKER TIMEOUT
• ReadTimeout
• RequestTimeout

What your security team should do

• Inventory applications and APIs that use python-multipart, especially internet-facing upload or form endpoints.
• Prioritize upgrading internet-facing and business-critical services to python-multipart 0.0.27 or later.
• Rebuild and redeploy containers, serverless packages, and virtual environments so the fixed dependency is present at runtime.
• Apply request size limits, header size limits, request timeouts, and rate limits for multipart/form-data endpoints at reverse proxies, API gateways, and WAFs.
• Monitor for spikes in HTTP 4xx/5xx responses, request latency, CPU utilization, and repeated multipart/form-data POST requests with unusually large or numerous part headers.
• Add dependency policy checks to block python-multipart versions earlier than 0.0.27 in future builds.