GHSA-x8mw-p69m-v3mx: High severity npm/@fastify/busboy vulnerability
Impact
Versions of @fastify/busboy from 1.0.0 and prior to 3.2.1 are vulnerable to a Denial of Service. The multipart header parser stores part-header names on a plain JavaScript object, so a part header named proto or constructor resolves to an inherited value that is not an array, and the parser throws TypeError: this.header[h].push is not a function. Through the documented req.pipe(busboy) integration this surfaces as an error event, while direct write()/end() usage throws synchronously and can terminate the Node.js process if uncaught. The parser runs before application middleware, so any unauthenticated client that can submit multipart/form-data is affected.
Patches
Fixed in version 3.2.1.
Workarounds
Attach an error listener to the Busboy stream so the parser failure is handled rather than crashing the process, and wrap direct write()/end() calls in a try/catch. Upgrading to 3.2.1 removes the failure entirely.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/@fastify/busboyto a version that resolves this vulnerability.Fixed in 3.2.1 - Upgrade
Upgrade
@fastify/busboyto a version that resolves this vulnerability.Fixed in 3.2.1 - Compensating control
Attach an error listener to the Busboy stream and wrap direct write()/end() calls in try/catch so parser failures are handled rather than crashing the process.
Event History
Frequently Asked Questions
Which deployments are exposed to this denial-of-service condition?
Deployments using @fastify/busboy versions 1.0.0 through versions before 3.2.1 are affected if unauthenticated clients can submit multipart/form-data. The vulnerable parser runs before application middleware, so middleware-based authentication does not prevent the parser from being reached.
What does an attacker need to send to trigger the failure?
An attacker only needs to submit a multipart/form-data request containing a part header named __proto__ or constructor. No authentication or user interaction is required.
Does the impact differ by integration method?
With the documented req.pipe(busboy) integration, the parser failure is emitted as an error event. With direct write() or end() usage, it throws synchronously and can terminate the Node.js process if the exception is uncaught.
What can be done if upgrading is not immediately possible?
Attach an error listener to the Busboy stream so the parser failure is handled rather than crashing the process. For direct write() or end() usage, wrap those calls in try/catch.
What version fixes the issue?
Upgrade @fastify/busboy to version 3.2.1. This removes the failure entirely.