CVE-2026-40347

What it actually does

Python-Multipart versions prior to 0.0.26 can consume excessive processing resources while parsing specially crafted multipart/form-data HTTP requests that contain very large preamble or epilogue sections. Because multipart parsing commonly happens before application request handling, an unauthenticated remote client may be able to degrade availability of web APIs or upload endpoints that rely on the vulnerable parser. The impact is limited to availability; the vulnerability does not directly provide data access, code execution, or privilege escalation.

Why it matters to the business

Applications that accept multipart/form-data uploads or form submissions through vulnerable Python-Multipart versions may experience slow responses, elevated CPU usage, request backlogs, worker exhaustion, or partial service outages when targeted with crafted requests. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, so broad active exploitation is not indicated; however, public internet-facing upload endpoints are practical denial-of-service targets and should be upgraded during normal patch cycles, or sooner for critical services.

How an attack unfolds

An attacker identifies an application endpoint that accepts multipart/form-data, such as a file upload or form submission endpoint, and sends HTTP POST requests with a multipart body containing an abnormally large preamble before the first boundary or excessive epilogue data after the closing boundary. In vulnerable Python-Multipart releases, parsing this crafted structure can require disproportionate work or retain processing longer than expected. By repeating these requests or sending them concurrently, the attacker can tie up application workers or increase CPU utilization, leading to degraded throughput or denial of service for legitimate users.

How to fix it

Upgrade Python-Multipart to version 0.0.26 or later wherever it is present, including transitive dependencies used by frameworks such as FastAPI or Starlette. Regenerate and redeploy lockfiles, container images, and serverless artifacts so the patched package is actually used at runtime. If immediate upgrade is not possible, reduce exposure by enforcing request body size limits, upload size limits, header and body read timeouts, reverse-proxy buffering limits, and per-client rate limits on multipart endpoints. Consider temporarily restricting unauthenticated upload endpoints or placing them behind authentication, WAF rules, or traffic-shaping controls until patched.

How to confirm the fix worked

Confirm that deployed runtime environments report python-multipart version 0.0.26 or later using package inventory, pip freeze, pip show python-multipart, SBOMs, container image scans, or dependency lockfile review. Validate that all production artifacts were rebuilt after the dependency update and that no older version remains in virtual environments, containers, or serverless layers. Test multipart upload endpoints with normal files and forms to ensure expected functionality remains intact. Also verify that front-end proxies, application servers, and frameworks enforce maximum request body sizes and request timeouts for multipart/form-data traffic.

Typical attack path

1. Identify a Python web application endpoint that accepts multipart/form-data requests, commonly file upload or form submission routes.
2. Craft a multipart/form-data request with a valid Content-Type boundary but an unusually large preamble and/or epilogue section.
3. Send the request to force the vulnerable parser to spend excessive time processing leading CR/LF or trailing data.
4. Repeat or parallelize requests to increase CPU usage, occupy worker threads/processes, and reduce service availability.
5. Maintain pressure until request queues grow, response times increase, health checks fail, or the service becomes unavailable.

How to detect it

Look for evidence of availability-focused abuse against multipart/form-data endpoints. Relevant log sources include reverse proxy logs, load balancer access logs, WAF logs, API gateway logs, application access logs, application error logs, APM traces, and host/container CPU metrics. Hunt for repeated HTTP POST requests with Content-Type multipart/form-data, unusually large request bodies, long request durations, client disconnects, gateway timeouts, upstream timeouts, or bursts from a small set of IP addresses. Application logs may show request timeout exceptions, worker restarts, queue saturation, or elevated latency around upload or form-processing routes. Because this vulnerability does not create a unique file, process, registry artifact, or command execution trace, detection is primarily behavioral and traffic-based rather than based on a stable host IOC.

• Content-Type: multipart/form-data
• boundary=
• HTTP 413
• HTTP 408
• HTTP 499
• HTTP 502
• HTTP 503
• HTTP 504
• upstream timed out
• client intended to send too large body
• request body is too large
• multipart/form-data POST
• python-multipart<0.0.26

What your security team should do

• Inventory applications and services that include python-multipart, especially internet-facing APIs and upload endpoints.
• Prioritize upgrading exposed or business-critical services to python-multipart 0.0.26 or later.
• Add or verify reverse proxy, load balancer, and application-level limits for multipart/form-data request size, upload duration, and per-client request rate.
• Monitor for spikes in multipart/form-data POST traffic, large request bodies, elevated 4xx/5xx responses, worker timeouts, and CPU saturation.
• Ensure dependency scanning and SBOM tooling detect vulnerable python-multipart versions in source repositories, CI artifacts, containers, and deployed runtime images.
• If patching is delayed, deploy compensating WAF or gateway rules to block multipart requests with excessive body size or abnormal boundary structure.