If your service uses FastAPI or Starlette to handle form uploads, you almost certainly depend on python-multipart, and versions before 0.0.18 carry a denial-of-service vulnerability you should patch. python-multipart is a streaming parser for multipart/form-data request bodies, and because FastAPI and Starlette pull it in to handle file uploads and form fields, a lot of teams ship it without ever having chosen it directly. That is exactly the kind of transitive dependency that quietly becomes a liability.
This post explains the flaw, how to tell if you are exposed, and the broader habits that keep parser dependencies from biting you.
The Vulnerability: CVE-2024-53981
The issue is tracked as CVE-2024-53981, a denial of service via a deformed multipart/form-data boundary. The parser handled bytes before the first boundary and after the last boundary one byte at a time, emitting a log event for each byte it skipped. An attacker who sends a request with a large volume of data before the first boundary or after the last one triggers a flood of logging, which drives high CPU load.
In an ASGI application the practical impact is severe: the excessive work can stall the event loop, so the process stops handling other requests. One malicious upload can degrade an entire service. The fix, shipped in python-multipart 0.0.18, changes the parser to skip those byte sequences atomically rather than logging per byte.
Are You Affected?
Because python multipart usually arrives transitively, the first step is finding what version you actually have, not what you think you have:
pip show python-multipart
Or inspect a locked environment:
pip freeze | grep -i multipart
If the version is below 0.0.18, you are exposed. Note that the distribution name has shifted over time; you may see it referenced as python-multipart or, in newer packaging, python_multipart. Check both. In a Poetry or pip-tools project, look at your lockfile rather than trusting a loose version range in your top-level manifest, since the range is not what got installed.
Fixing It
Upgrade directly:
pip install --upgrade "python-multipart>=0.0.18"
If it is pulled in by FastAPI or Starlette, upgrading those frameworks to a recent release usually bumps the constraint for you, but pinning python-multipart explicitly in your requirements guarantees the floor regardless of what the framework's range allows. After upgrading, rebuild your lockfile and redeploy so the running environment actually reflects the fix. It is common to "upgrade" a dependency in a manifest and still ship the old version because the lockfile was never regenerated.
Why Transitive Parser Bugs Are So Common
Parsers that consume untrusted input are a recurring source of denial-of-service bugs, and multipart parsers are a classic example because the format is fiddly: boundaries, headers, streaming chunks, and edge cases around malformed input. The python-multipart flaw is a textbook algorithmic-complexity issue, where handling malformed input inefficiently turns a small request into a large amount of work.
The reason these bite teams is visibility. You did not add python-multipart; a framework did. It never appears in a design review. It surfaces only when someone scans the full dependency tree. This is the core argument for software composition analysis: an SCA tool such as Safeguard can flag a vulnerable transitive package like python-multipart even when nothing in your own code references it directly, mapping the installed version to the advisory automatically.
Hardening Form Uploads Beyond the Patch
Patching the CVE is necessary but not the whole story. Defensive limits on upload handling reduce the impact of the next parser bug too:
- Cap request body size at the ingress (reverse proxy or ASGI server) so an oversized body is rejected before your parser ever sees it. This directly blunts the class of attack CVE-2024-53981 used.
- Set a maximum number of form fields and files per request if your framework supports it.
- Enforce timeouts on request reads so a slow or oversized upload cannot tie up a worker.
- Rate-limit upload endpoints specifically, since they are more expensive to process than a typical GET.
These controls are generic and outlast any single CVE. If a future multipart parsing bug lands, a body-size cap at the proxy may block the attack regardless of the parser's internal behavior.
Keeping It From Recurring
The lasting fix is process, not a one-time upgrade:
- Generate and store an SBOM so you know every transitive package, including python-multipart, that ships in each build.
- Run continuous dependency scanning so a newly disclosed CVE against an installed version alerts you without manual checking.
- Pin security-relevant floors explicitly rather than trusting a framework's loose range.
- Regenerate lockfiles and redeploy after upgrades; verify the running version.
FAQ
What is CVE-2024-53981?
It is a denial-of-service vulnerability in python-multipart where the parser processed data before the first boundary and after the last boundary one byte at a time, logging each byte. An attacker sending large amounts of such data causes excessive CPU load that can stall an ASGI event loop. It is fixed in version 0.0.18.
Do I use python-multipart even if I never installed it?
Very likely, if you use FastAPI or Starlette to handle form or file uploads. Both pull python multipart in transitively. Run pip show python-multipart to confirm and check the version.
How do I fix the python-multipart DoS?
Upgrade to python-multipart>=0.0.18, regenerate your lockfile, and redeploy. Pinning the version explicitly in your requirements guarantees the fixed floor even if a framework's dependency range would otherwise allow an older release.
Is upgrading enough on its own?
Upgrading closes this specific flaw, but capping request body size at your proxy, limiting form fields, and rate-limiting upload endpoints protect you against the broader class of parser DoS bugs, including ones not yet disclosed.