The busboy npm package is a widely used, low-level streaming parser for multipart/form-data in Node.js, and its current version 1.6.0 has no known CVEs, but its history and its role in handling untrusted uploads make it worth reviewing before you trust it. If you accept file uploads in a Node service, busboy is very likely somewhere in your dependency tree, whether you installed it directly or pulled it in through Express, Fastify, or Multer.
What busboy does
Busboy takes the raw HTTP request stream and emits events as it encounters fields and files inside a multipart body. It does not buffer the whole upload into memory or write files to disk for you. It hands you a stream per file and lets you decide what to do. That streaming design is exactly why it sits under so many higher-level libraries: it is fast, it does not assume a storage strategy, and it stays out of your way.
A minimal usage with the modern API looks like this:
const Busboy = require('busboy');
function handleUpload(req, res) {
const bb = Busboy({
headers: req.headers,
limits: { fileSize: 5 * 1024 * 1024, files: 3, fields: 20 },
});
bb.on('file', (name, stream, info) => {
// stream the file somewhere; DO enforce the limit
stream.on('limit', () => {
// fileSize limit hit — reject
});
});
bb.on('error', (err) => res.writeHead(400).end());
req.pipe(bb);
}
The npm busboy download count is enormous, in the tens of millions per week, which is both reassuring and a reason to pay attention: anything that popular is a valuable target for anyone probing the ecosystem.
The dicer history you should know
The most important security story around busboy is its former dependency, dicer. Older busboy releases in the 0.x line relied on dicer to do the low-level multipart parsing. Dicer carried CVE-2022-24434, a denial-of-service issue where a malicious attacker could send a crafted multipart request that crashed the Node process by triggering an unhandled exception in the parser.
Busboy 1.x was rewritten so it no longer depends on dicer, which is the main reason the current 1.x line does not inherit that vulnerability. If your lockfile still resolves busboy to a 0.x version, or pulls dicer in through some other path, that is the finding to chase down. Run:
npm ls busboy dicer
If you see dicer or a busboy below 1.0, upgrade. This is exactly the kind of transitive exposure an SCA tool can surface for you across a whole monorepo instead of one npm ls at a time.
Current maintenance status
Busboy 1.6.0 has no known vulnerabilities today. The one caveat is cadence: the package has not shipped a new release to npm in over a year at the time of writing, which some scanners flag as a low-maintenance or potentially unmaintained signal. That is not the same as vulnerable. A small, stable, single-purpose parser that has reached a mature API can legitimately go quiet. But it does mean that if a new issue is disclosed, a fix may not arrive quickly, so you should track it rather than assume it will always be patched promptly.
Using npm busboy safely
The security of a multipart parser is mostly about what you do with the streams it hands you, because busboy deliberately does no policy enforcement of its own. A few rules matter.
Always set limits. The limits option is your first line of defense against upload-based denial of service. Cap fileSize, files, fields, fieldSize, and parts. Without them, an attacker can stream an unbounded body and exhaust disk or memory. Critically, when a fileSize limit is hit, busboy emits a limit event on the file stream but does not automatically abort the request, so you have to handle it and stop consuming.
Never trust the filename. The info.filename is attacker-controlled. Do not use it to build a path on disk. Generate your own identifier and store the original name only as metadata. A raw filename can carry ../ traversal sequences or null bytes.
Validate content type by inspection, not by claim. The info.mimeType busboy reports comes from the request. If you only accept images, sniff the actual bytes after upload rather than believing the declared type.
Drain streams you reject. If you decide not to keep a file, you still need to consume or destroy its stream, or the request can hang and hold resources.
For a broader treatment of how upload endpoints get abused, our academy covers file-upload hardening patterns that apply regardless of which parser you choose.
Should you use it directly or through a wrapper?
Most applications do not use busboy directly. They use Multer, @fastify/multipart, or connect-busboy, which layer a friendlier API and, in some cases, sane default limits on top. Those wrappers are fine, but remember that they inherit busboy's behavior underneath. Whatever you use, confirm the resolved version, set explicit limits, and treat every field and filename as hostile input.
FAQ
Does the busboy npm package have any known vulnerabilities right now?
The current version, 1.6.0, has no known CVEs. Older 0.x versions depended on dicer, which carried CVE-2022-24434, a denial-of-service issue, so upgrading off the 0.x line is the key action.
Is npm busboy still maintained?
It is stable but quiet. It has not had a new npm release in over a year, which some tools flag as low maintenance. That is a reason to monitor it, not necessarily to replace it.
Do I need to set limits manually with busboy?
Yes. Busboy does not impose default size or count limits. You must pass a limits object and handle the limit event yourself, or you expose the endpoint to upload-based denial of service.
Is Multer safer than raw busboy?
Multer is built on busboy, so it inherits the same underlying parser. It adds a more convenient API and some default handling, but you still must configure limits and validate filenames and content types.