npm body-parser is the Node.js body-parsing middleware behind most Express applications, and it is safe to use as long as you stay on version 1.20.3 or later, which patches CVE-2024-45590 — a denial-of-service flaw affecting all earlier releases when URL-encoded parsing is enabled. If you build APIs on Express, body-parser is almost certainly in your dependency tree, so it is worth understanding the one advisory that actually matters and how to configure the middleware so it is not a soft target.
This review covers what the package does, the CVE-2024-45590 issue in detail, and the defensive settings that keep it out of trouble.
What body-parser does
body-parser is Express middleware that reads the incoming request body and exposes it as req.body in a parsed form. It ships several parsers: JSON, URL-encoded, raw, and text. In modern Express (4.16+ and Express 5), these are also available directly as express.json() and express.urlencoded(), which are the same body-parser code re-exported. So even if bodyparser does not appear by name in your package.json, you are almost certainly running it transitively.
Basic usage:
const express = require('express');
const bodyParser = require('body-parser');
const app = express();
app.use(bodyParser.json({ limit: '100kb' }));
app.use(bodyParser.urlencoded({ extended: false, limit: '100kb' }));
Note the limit on both — we will come back to why that matters.
CVE-2024-45590: the denial-of-service flaw
The one advisory every body-parser user should know is CVE-2024-45590. It affects all versions before 1.20.3 and carries a CVSS v3 base score of 7.5 (high). The problem: when URL-encoded parsing is enabled, a specially crafted payload could force the middleware to process an excessive number of requests or entries, exhausting resources and denying service to legitimate traffic. It is tracked publicly as GHSA-qwcr-r2fm-qrc7.
Two points make this practical rather than theoretical. First, URL-encoded parsing is extremely common — any classic HTML form POST uses it — so the vulnerable path is one most apps actually exercise. Second, because so much of the ecosystem depends on body-parser transitively through Express, you can be exposed without ever having added it yourself.
The fix is straightforward: upgrade to 1.20.3 or later. If you cannot upgrade immediately, the documented mitigation is to reduce exposure by disabling or tightening URL-encoded parsing where you do not need it, but upgrading is the real remedy.
Checking whether you are exposed
Because the dependency is often transitive, check the resolved version rather than what you declared:
npm ls body-parser
If any resolved instance is below 1.20.3, you have a vulnerable copy somewhere in the tree, even if your top-level Express is recent. Update Express and body-parser, then re-run the command to confirm the tree resolves to a patched version. An SCA tool such as Safeguard can flag this kind of transitive exposure automatically across all your services, which beats running npm ls by hand on every repo.
Defensive configuration beyond patching
Upgrading closes the known CVE, but body-parser sits at the edge of your application where untrusted input arrives, so a few settings harden it regardless of any specific advisory.
Set an explicit limit on every parser. The default JSON limit is 100kb, but making it explicit and sizing it to your real payloads prevents attackers from forcing your process to buffer huge bodies. A tighter limit on endpoints that only expect small JSON is free defense-in-depth.
Prefer extended: false on urlencoded unless you genuinely need rich nested objects. The extended parser uses the qs library and permits deeply nested structures, which historically has been a source of resource-exhaustion concerns. If flat key-value pairs cover your needs, the simpler parser is a smaller surface.
Scope parsers to routes that need them. Applying bodyParser.json() globally means every request, including ones with no body, runs through the parser. Mounting it only on routes that accept bodies reduces unnecessary processing.
Validate after parsing. body-parser turns bytes into a JavaScript object; it does not tell you whether that object is well-formed for your endpoint. Pair it with a schema validator so malformed or oversized structures are rejected before your handler touches them.
Is body-parser well maintained?
Yes. body-parser is a core piece of the Express ecosystem, maintained alongside it, and the CVE-2024-45590 response — a clear advisory and a prompt patched release in 1.20.3 — is exactly the responsible-disclosure behavior you want from a critical dependency. The package is not abandonware, and there is no reason to seek an exotic replacement. Keep it current, configure it defensively, and it is a safe foundation. For more on evaluating whether a dependency is healthy enough to trust, see our OpenSSF Scorecard guide.
FAQ
Is npm body-parser safe to use?
Yes, provided you run version 1.20.3 or later. That release patches CVE-2024-45590, the notable denial-of-service issue. body-parser is a well-maintained core part of the Express ecosystem, so the main requirement is keeping it current and setting sensible parser limits.
What is CVE-2024-45590 in body-parser?
It is a high-severity (CVSS 7.5) denial-of-service vulnerability affecting body-parser versions before 1.20.3. When URL-encoded parsing is enabled, a crafted payload can exhaust server resources. Upgrading to 1.20.3 or later resolves it.
Do I need body-parser if I use express.json()?
Functionally you are already using it. express.json() and express.urlencoded() are body-parser's parsers re-exported by Express since 4.16, so the same code and the same CVE apply. Keep your Express version current to pull in the patched body-parser.
How do I check which body-parser version I have?
Run npm ls body-parser to see every resolved instance in your dependency tree, including transitive ones pulled in through Express. If any resolves below 1.20.3, update and re-run the command to confirm the tree now resolves to a patched release.