@fastify/multipart vulnerable to Denial of Service via a malformed upload hanging delayed file consumers
Only affects @fastify/multipart 5.3.0 up to 10.1.7 in handlers that call request.parts() and do asynchronous work before consuming part.file. Fixed in 10.1.7.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- Fixed in 10.1.7
- Who is exposed
- Not reported
Do first: Upgrade to a fixed version: 10.1.7.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 13/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Fix
- Fixed in 10.1.7
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
@fastify/multipart, the multipart form-data and file upload plugin for the Fastify web framework, can be made to hang requests when a malformed upload ends inside a file part without a closing boundary. An unauthenticated remote attacker can repeat such uploads against a route that consumes files after asynchronous work, leaving connections open and never answered, which can exhaust server resources and cause a denial of service.
Read the original description
@fastify/multipart is the multipart form-data and file upload plugin for the Fastify web framework. In versions 5.3.0 through 10.1.6, the plugin does not propagate a parser error to the file stream when a request body ends inside a file part with no closing boundary, even though the Content-Length is complete, the client does not abort, and no file size limit is exceeded. The plugin destroys the in-progress file stream without an error, so a handler that iterates the request parts and performs asynchronous work before consuming the file attaches to a stream that never emits an error or end event, and the request never responds while the connection stays open. An unauthenticated remote client can repeat these malformed uploads against such a route to accumulate pending connections and exhaust server resources, so the impact is availability only and exploitation depends on the application using a delayed file consumer. The issue is fixed in @fastify/multipart 10.1.7, where the parser error is propagated to the file stream so a delayed consumer settles with an error instead of hanging, and users should upgrade to 10.1.7 or later. There is no workaround other than upgrading.
What to do
Upgrade to a fixed version: 10.1.7.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- @fastify/multipart @fastify/multipart
From 5.3.0 · fixed in 10.1.7
Evidence 2
- Advisory
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-117531
What does this mean?
A malformed upload whose request body ends inside a file part, with no closing boundary, can leave the request hanging without a response while the connection stays open. Repeated malformed requests to such a route pile up pending connections and can exhaust server resources. The impact is on availability only.Source: github.com
Am I affected, and how do I check?
Affected versions are @fastify/multipart 5.3.0 up to but not including 10.1.7, in applications whose handler uses request.parts() and performs asynchronous work before consuming part.file. To check, look at the installed @fastify/multipart version with npm ls @fastify/multipart or in package.json and review whether the upload route uses request.parts().Source: github.com
What should I do about it?
Upgrade to @fastify/multipart 10.1.7, which is the fixed version named in the advisory.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data