EUVD-2026-59759Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Network-reachable upload endpoint, no authentication required per description; A:H for unbounded disk and event-loop exhaustion; C:N and I:N as no data is read or modified.
Primary rating from Vendor (ce714d77-add3-4f53-aff5-83d477b104bb).
CVSS VectorVendor: ce714d77-add3-4f53-aff5-83d477b104bb
Lifecycle Timeline
3DescriptionCVE.org
@fastify/multipart is a multipart form-data parser for Fastify. In 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 then aborts the connection before sending the terminating boundary, the abort cleanup finds no stream to destroy, so saveRequestFiles() never settles, the request handler hangs, and the temporary file already written to disk 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 @fastify/multipart 10.1.1. Users should upgrade to 10.1.1.
AnalysisAI
Uncontrolled resource consumption in @fastify/multipart (versions 5.3.0 through 10.1.0) allows any unauthenticated remote client to permanently leak temporary files on disk and suspend Fastify request handler executions, ultimately exhausting both disk space and the Node.js event loop. The root defect is a state-management flaw: when busboy's fileSize limit truncates an incoming file part, the plugin prematurely clears its internal stream reference, so a subsequent client-initiated abort finds nothing to clean up, leaving saveRequestFiles() awaiting a settlement that never arrives. No public exploit code has been identified at the time of analysis, but the attack is trivially repeatable with standard HTTP tooling, making this a realistic denial-of-service risk for any service that accepts multipart file uploads from untrusted clients.
Technical ContextAI
The affected package, @fastify/multipart, is the official Fastify plugin for parsing multipart/form-data HTTP requests and is implemented on top of the busboy streaming parser. CWE-400 (Uncontrolled Resource Consumption) accurately describes the root cause: a lifecycle mismatch between busboy's internal stream state and the plugin's own reference tracking. When busboy enforces a developer-configured fileSize limit, it truncates the stream and signals completion, at which point the plugin zeroes out its currentFile pointer. However, the underlying Readable stream remains open and unresolved. If the TCP client then abruptly closes the connection - without sending the MIME multipart terminating boundary - the plugin's abort handler finds currentFile === null, skips stream cleanup, and the awaited saveRequestFiles() Promise never resolves or rejects. The result is a permanently suspended async handler and an orphaned temporary file in the OS temp directory. Affected versions span 5.3.0 to 10.1.0 inclusive, as confirmed by EUVD-2026-59759 and the upstream GitHub advisory GHSA-vmph-573x-85f6.
RemediationAI
The primary fix is to upgrade @fastify/multipart to version 10.1.1, which resolves the stream-reference lifecycle bug, as confirmed by the vendor advisory at https://github.com/fastify/fastify-multipart/security/advisories/GHSA-vmph-573x-85f6 and EUVD-2026-59759. If an immediate upgrade is not feasible, the following compensating controls can reduce exposure: require authentication on all multipart upload endpoints to eliminate unauthenticated exploitation (trade-off: breaks public upload workflows); apply aggressive per-IP rate limiting on upload routes using a Fastify rate-limit plugin to constrain the attacker's ability to accumulate leaked resources at scale (trade-off: may affect legitimate high-volume uploaders); set a temp-file cleanup job (e.g., a cron task targeting the OS temp directory) to periodically remove stale files, preventing disk exhaustion from accumulating (trade-off: does not stop handler suspension or event-loop saturation); and monitor Node.js event-loop lag and disk usage on the temp partition to detect exploitation attempts early. None of these workarounds eliminate the underlying defect - upgrading to 10.1.1 is the definitive resolution.
All versions of @fastify/oauth2 used a statically generated state parameter at startup time and were used across all req
A redirect vulnerability in the `fastify-static` module version >= 4.2.4 and < 4.4.1 allows remote attackers to redirect
Fastify is a fast and low overhead web framework, for Node.js. Rated high severity (CVSS 7.5), this vulnerability is rem
Prototype pollution vulnerability in fastify-multipart < 1.0.5 allows an attacker to crash fastify applications parsing
Fastify node module before 0.38.0 is vulnerable to a denial-of-service attack by sending a request with "Content-Type: a
A denial of service vulnerability exists in Fastify v2.14.1 and v3.0.0-rc.4 that allows a malicious user to trigger reso
A redirect vulnerability in the fastify-static module version < 4.2.4 allows remote attackers to redirect users to arbit
Authorization bypass in the @fastify/express middleware-compatibility plugin (versions 4.0.6 and earlier) lets unauthent
Authentication bypass in @fastify/express v4.0.4 and earlier allows remote unauthenticated attackers to access protected
Middleware bypass in Fastify Express plugin (fastify/express) allows complete circumvention of authentication, authoriza
Fastify is a web framework with minimal overhead and plugin architecture. Rated high severity (CVSS 8.8), this vulnerabi
Authentication and authorization bypass in @fastify/middie (Node.js middleware library for Fastify) allows remote unauth
Same weakness CWE-400 – Uncontrolled Resource Consumption
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today