CVE-2026-19481

This CVE reveals a trap in @fastify/busboy that goes beyond a typical prototype pollution flaw: the library exposes two execution models with fundamentally different failure modes, and the documented integration path is the safer one by accident, not by design. When you use the parser with Fastify's pipe integration (the documented pattern), a malformed multipart request triggers a TypeError that surfaces as a handled error event—the request fails gracefully. But when code directly invokes write() or end() on the parser (an implementation detail that leaks through the API), the same underlying prototype pollution flaw throws synchronously and terminates the Node process. Both paths hit the same vulnerable code: a plain JavaScript object used as a dictionary for parsed headers. The difference is purely in how the error propagates. The fix—replacing the plain object with Object.create(null)—is trivially simple, which is exactly why this went undetected for four years across eight minor versions. The original developer wrote the obvious code. Nothing in the development workflow flagged it. eslint-plugin-security exists, but it isn't a default gate in most CI pipelines, and npm audit doesn't surface prototype pollution in plain objects as a first-class finding. This isn't negligence; it's a structural tooling gap that the JavaScript security community has documented extensively since 2017 yet never embedded into standard dependency pipelines with sufficient friction to prevent recurrence. The 7.5 CVSS score and 0.00278 EPSS both miss the real exposure. @fastify/busboy is a direct dependency of Fastify—the most deployed production-grade Node.js HTTP framework. The exploitation bar isn't "attacker must target this specific integration point"; it's "attacker sends malformed multipart data to any Fastify upload endpoint and the process dies." That blast radius is orders of magnitude larger than the technical severity score implies. Your action items: First, upgrade to 3.2.1 immediately—any Fastify application handling file uploads is running this code. Second, audit your codebase for direct write()/end() usage on multipart parsers even if you think you're only using pipe integration; middleware or transitive dependencies may be invoking the synchronous path. Third, advocate for Object.create(null) becoming a lint rule in your project's JavaScript standards—the pattern is so well-documented in CVEs that it should require explicit justification, not the reverse.

Reviewed through automated stages and approved by a human before publication.