CVE-2026-117531
MediumCVSS 5.9Summary
@fastify/multipart versions 5.3.0 through 10.1.6 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 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 doing asynchronous work before consuming the file attaches to a stream that never emits an error or end event, and the request never responds.
Risk Assessment
An unauthenticated remote client can repeat these malformed uploads against such a route to accumulate pending connections and exhaust server resources. The impact is availability only and depends on the application using a delayed file consumer.
Recommendation
Upgrade @fastify/multipart to version 10.1.7 or later. There is no workaround other than upgrading.
Other vulnerabilities in @fastify/multipart
See all- CVE-2026-19474High
In @fastify/multipart, a multipart form-data parser for Fastify, versions from 3.0.0 up to but not including 10.1.1, request.saveRequestFiles() can leave completed temporary files on disk when a client disconnects during processing. An unauthenticated client can repeat this to cause persistent disk consumption and denial of service. The issue is fixed in version 10.1.1.
- CVE-2026-18549High
In @fastify/multipart, versions from 5.3.0 up to but not including 10.1.1, when the busboy fileSize limit truncates a file part, the plugin clears its internal current-file reference while the underlying stream is still open. If the client aborts the connection before sending the terminating boundary, saveRequestFiles() never settles, and the temporary file is never cleaned up. An unauthenticated client can repeat this to permanently leak temporary files and suspended handler executions, leading to disk and event-loop exhaustion. The issue is fixed in version 10.1.1.
Original NVD description (English source)
@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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS