CVE-2024-53981

What it actually does

The flaw is a denial-of-service condition in python-multipart's streaming multipart/form-data parser. When a request contains large amounts of carriage-return or line-feed bytes before the first multipart boundary, or extra bytes after the final boundary, vulnerable versions process and log the skipped data one byte at a time. This can consume excessive CPU and I/O, amplify application logging, stall request-processing threads, and, in ASGI applications, block the event loop so unrelated requests cannot be served. The issue does not provide code execution, privilege escalation, or data disclosure; the primary impact is loss of availability.

Why it matters to the business

Internet-facing APIs, upload endpoints, form handlers, and services built on Python frameworks that rely on python-multipart can be slowed or made temporarily unavailable by unauthenticated requests. The operational impact can include degraded user experience, request timeouts, increased infrastructure costs from CPU and log volume spikes, alert noise, and possible cascading failures if the affected service is part of a larger transaction flow. Although it is not listed in CISA KEV, has low EPSS at 0.00644, and has no known mature public exploitation noted in the input, it is a low-complexity network denial-of-service issue published for a long time and should be treated as hygiene debt if still present.

How an attack unfolds

An attacker identifies an HTTP endpoint that accepts multipart/form-data, such as a file upload or form submission endpoint. They send crafted POST requests with a valid or plausible multipart Content-Type and boundary value, but place a very large sequence of CR/LF bytes before the first boundary or append a large amount of trailing data after the closing boundary. A vulnerable python-multipart parser skips those bytes one at a time and emits a log event for each skipped byte. Repeating the request, or sending several requests concurrently, can drive CPU utilization high, create excessive log writes, and tie up application workers. In ASGI deployments, the parser behavior can stall the event loop, delaying or preventing processing of otherwise legitimate requests.

How to fix it

Upgrade python-multipart to version 0.0.18 or later wherever it is used directly or transitively. For source-based deployments of kludex/python-multipart, ensure the code includes commit 5b1aed83adadbff1677779cd0df53723cd80a0d6 or a later release containing the fix. Rebuild and redeploy application containers, virtual environments, and serverless artifacts so the patched dependency is actually present at runtime. If Ubuntu Pro 14.04 LTS systems include the affected libpodofo package from the provided advisory data, update to 0.9.0-1.2ubuntu0.1~esm1 or later. As compensating controls, enforce maximum request body sizes, apply upload-specific rate limits, set reverse-proxy and application timeouts, reject malformed multipart requests at the edge where feasible, and tune logging to avoid per-byte amplification from malformed parser input.

How to confirm the fix worked

Confirm the installed dependency version with package inventory, SBOM, lockfiles, and runtime checks such as pip show python-multipart, pip freeze, poetry.lock, requirements files, container image scans, and application build manifests. The safe target is python-multipart 0.0.18 or later, or a source build containing commit 5b1aed83adadbff1677779cd0df53723cd80a0d6. After patching, exercise representative multipart upload and form endpoints to confirm normal functionality. In a controlled non-production test, send malformed multipart requests with excessive leading CR/LF padding or trailing bytes and verify the service rejects or handles them without sustained CPU spikes, event-loop stalls, excessive log growth, or worker exhaustion. Validate edge controls by confirming request-size limits, rate limits, and timeout behavior are enforced before traffic reaches application workers.

Typical attack path

1. Discover application endpoints that accept multipart/form-data, commonly upload, import, avatar, attachment, or form submission routes.
2. Send a multipart/form-data request with a boundary parameter and an unusually large body containing many CR or LF bytes before the first boundary, or excessive trailing bytes after the terminating boundary.
3. Cause the vulnerable parser to iterate through the malformed padding byte by byte while generating excessive log events.
4. Repeat or parallelize the malformed requests to exhaust CPU, saturate logging, block worker threads, or stall the ASGI event loop.
5. Observe service degradation through slow responses, timeouts, elevated 5xx responses, or temporary unavailability.

How to detect it

To determine whether exploitation has already occurred, review web access logs, reverse-proxy logs, API gateway logs, WAF events, application logs, APM traces, and host/container metrics for periods of elevated CPU, request latency, worker timeouts, event-loop lag, log volume spikes, or increased 4xx/5xx responses associated with multipart/form-data POST requests. Focus on upload and form submission routes, especially requests with unusually large Content-Length values, long durations, client disconnects, repeated malformed multipart parsing errors, or many requests from the same source over a short interval. Application logs are particularly important because the vulnerable behavior emits repeated log events while skipping bytes before the first boundary or after the final boundary. Correlate suspect requests with infrastructure metrics showing CPU saturation, increased log ingestion, disk I/O pressure, ASGI worker stalls, or timeout exceptions. Because this is a denial-of-service flaw rather than a persistence or code-execution vulnerability, durable host artifacts may be limited; evidence is most likely in request telemetry, parser logs, performance metrics, and log-volume anomalies.

• Content-Type: multipart/form-data
• multipart/form-data; boundary=
• python-multipart
• multipart.multipart
• Skipping data before first boundary
• Skipping data after last boundary
• CR or LF found before first boundary
• Did not find boundary character
• Expected boundary character
• ASGI event loop blocked
• application timeout while reading multipart
• worker timeout
• upstream timed out
• client intended to send too large body
• request body too large

What your security team should do

• Inventory all Python applications and containers that expose multipart/form-data endpoints and use python-multipart directly or through frameworks such as ASGI-based web stacks.
• Prioritize patching internet-facing upload and form endpoints first, then internal services that accept large multipart bodies from semi-trusted clients.
• Upgrade python-multipart to 0.0.18 or later, rebuild deployment artifacts, and verify the patched version is present in running workloads rather than only in source repositories.
• Add or tighten maximum request body size limits, upload quotas, per-IP rate limits, and request timeout controls at the load balancer, reverse proxy, API gateway, and application layers.
• Monitor for abnormal multipart POST volume, large request bodies with high failure rates, CPU saturation, event-loop latency, worker timeouts, and sudden growth in parser-related log messages.
• Review logging configuration for multipart parsing paths to reduce the risk that malformed input can create excessive log ingestion costs or disk pressure.
• If vulnerable versions remain temporarily deployed, consider temporarily restricting unauthenticated upload endpoints or requiring stronger admission controls until patching is complete.