Description

@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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-15T14:17:07.590Z",
  "pubdate": "2026-08-15T14:17:07.590Z",
  "executiveSummary": "A denial of service vulnerability exists in the @fastify/multipart plugin for Fastify, specifically affecting versions from 5.3.0 up to but not including 10.1.1. The vulnerability is triggered when the underlying busboy parser fileSize limit truncates a file part, causing the plugin to prematurely clear its internal current-file reference while the underlying stream remains open. If an unauthenticated client subsequently aborts the connection prior to sending the terminating boundary, the internal abort cleanup logic fails to locate and destroy the active stream. Consequently, the saveRequestFiles() function never settles, causing the request handler to hang indefinitely and leaving orphaned temporary files stranded on disk without automated cleanup. An unauthenticated remote attacker can repeatedly exploit this behavior to induce severe resource exhaustion, leading to unmitigated disk space depletion and event loop degradation that impacts overall application availability. Remediation requires upgrading the @fastify/multipart package to version 10.1.1 or later.",
  "technicalDetails": "The vulnerability resides within the request processing and stream management logic of the @fastify/multipart plugin, specifically affecting versions 5.3.0 through 10.1.0. The vulnerable component fails to properly maintain state tracking between the internal current-file reference and the underlying readable stream when the busboy parser enforces a fileSize limit and truncates an incoming file part. During this truncation event, the plugin clears its internal reference to the current file prematurely, even though the underlying network stream remains open and active.\nThe attack flow proceeds as follows: First, an unauthenticated client initiates a multipart form-data upload containing a file engineered to exceed the configured busboy fileSize limit. Second, as the parser processes the stream and reaches the threshold, busboy truncates the file part, triggering the flawed state-handling mechanism in @fastify/multipart where the internal current-file reference is wiped out prematurely while the stream continues to consume data or remain open. Third, the malicious client abruptly aborts the connection before sending the final multipart terminating boundary. Fourth, when the server detects the client abortion, the abort cleanup routine executes but attempts to locate the active stream via the cleared internal reference, finding no stream to destroy.\nAs a direct result of this broken reference, the asynchronous saveRequestFiles() function never resolves or rejects, leaving the promise permanently unsettled. This causes the associated request handler execution to hang indefinitely. Furthermore, the temporary file written to disk prior to truncation is never deleted by the plugin's lifecycle management routine. By automating and repeating this sequence across multiple concurrent requests, an unauthenticated attacker can rapidly accumulate orphaned temporary files until disk capacity is exhausted, while simultaneously exhausting available event loop execution contexts and memory resources through hung request handlers, culminating in a complete denial of service for the Fastify application."
}