TL;DR: @fastify/multipart versions >=5.3.0 <10.1.1 can leak temporary files and leave request handlers suspended when an unauthenticated client sends an upload that crosses the configured fileSize limit and then disconnects before the closing multipart boundary. Repeating the pattern can exhaust disk space and worker or event-loop capacity. The Fastify maintainers rate the issue 7.5 HIGH. Upgrade to 10.1.1.

What happened

The vulnerable path is request.saveRequestFiles(). When a file part reaches the fileSize limit, the multipart parser truncates the stream. In affected versions, the plugin can clear its reference to the current file while the underlying stream is still open. If the client aborts before sending the terminating multipart boundary, the abort cleanup no longer has the stream reference it needs to tear the request down correctly.

The result is two persistent resources from a request that should have disappeared: the temporary file already written into os.tmpdir(), and a request handler that never settles. Because exploitation does not require authentication, a remote client can repeat the request and steadily consume disk space and server capacity.

The vendor advisory assigns CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, or 7.5 HIGH. It maps the weakness to CWE-400 for uncontrolled resource consumption and CWE-664 for improper control of a resource through its lifetime.

Who is affected

Applications using @fastify/multipart from version 5.3.0 up to, but not including, 10.1.1 are affected when they use request.saveRequestFiles() with a file-size limit. The plugin has more than one million weekly npm downloads, so even a configuration-specific flaw has a large potential deployment footprint.

A separate same-day issue, CVE-2026-19474, also affects saveRequestFiles(). That flaw can leave completed temporary files behind when a client disconnects while the parser advances between multipart parts. Both issues are fixed in the same release, 10.1.1.

What to do

Upgrade immediately:

npm install @fastify/[email protected]

For pnpm:

pnpm up @fastify/[email protected]

For Yarn:

yarn add @fastify/[email protected]

If you cannot upgrade immediately, the Fastify advisory says setting throwFileSizeLimit: false avoids the specific code path involved in CVE-2026-18549. Otherwise, avoid saveRequestFiles() on routes exposed to untrusted clients until patched. For the related CVE-2026-19474 cleanup issue, explicitly calling request.cleanRequestFiles() when saveRequestFiles() rejects is the documented workaround.

Why this matters

Upload endpoints often sit directly on the public internet. This issue turns normal multipart parsing into an availability boundary: the attacker does not need a valid account, a large payload, or code execution. The vulnerable cleanup path lets inexpensive aborted requests leave durable server-side cost behind.

Teams running Fastify should inventory services that accept multipart uploads, check the deployed @fastify/multipart version, and confirm that temporary-storage monitoring and disk alerts are in place. If a service has already been exposed on an affected version, inspect the operating system temporary directory for unexpected accumulation.

References

• Fastify advisory for CVE-2026-18549
• Fastify advisory for CVE-2026-19474
• @fastify/multipart on npm
• CVE-2026-18549 CVE List record