body-parser Invalid Limit Denial of Service Vulnerability
Impact: In body-parser versions prior to 1.20.6 (1.x line) and 2.3.0 (2.x line), when the parser is configured with an invalid limit option value such as an unparseable string or NaN, bytes.parse returns null and the request body size check is silently skipped. Applications that rely on limit as their primary safeguard against oversized request bodies will accept arbitrarily large payloads, leading to excessive memory and CPU usage and denial of service. Patches: This issue is fixed in body-parser 1.20.6 and 2.3.0. After the fix, invalid limit values throw a clear error at parser construction time instead of silently disabling enforcement, while null and undefined continue to fall back to the default limit of 100kb. Workarounds: Validate the limit value before passing it to body-parser. For example, parse the value at startup and reject any configuration where the result is null or a non-finite number.
Quick answer
Express.js body-parser should be reviewed and updated if it matches the affected versions. The recommended fix is to apply the vendor-supported patched version or the mitigation steps below, then retest the public website with Fixnx.
Who is affected
Affected versions
- body-parser 1.x before 1.20.6
- body-parser 2.x before 2.3.0
Fixed versions
- 1.20.6
- 2.3.0
How to fix it
body-parser is affected by CVE-2026-12590. Applications using vulnerable body-parser 1.x before 1.20.6 and 2.x before 2.3.0 can lose request body size protection when the limit option is invalid, because invalid limit values can silently disable request body size enforcement and allow oversized payloads. Upgrade to 1.20.6 or 2.3.0 and validate parser configuration at startup.
- Inventory Node.js services and packages that depend on body-parser directly or through Express middleware.
- Upgrade body-parser 1.x to 1.20.6 or later, or body-parser 2.x to 2.3.0 or later.
- Regenerate lockfiles and rebuild containers so the patched dependency is actually deployed.
- Validate body-parser limit configuration at startup and fail closed if the parsed value is null, NaN, or non-finite.
- Set explicit request size limits at the reverse proxy or edge layer as a second control.
- Monitor memory, CPU, and 413/request-size rejection metrics for abnormal large body attempts.
- Redeploy from trusted artifacts and remove old vulnerable images from registries and caches.
Scan now. Google sign-in is only needed to unlock fix guidance.
Verify the fix
- Confirm package-lock, pnpm-lock, yarn.lock, or npm ls shows body-parser 1.20.6/2.3.0 or later.
- Start the service with an intentionally invalid limit in staging and confirm startup fails clearly.
- Send an oversized request body in staging and confirm it is rejected by application or edge limits.
- Check production telemetry after deployment for memory spikes or body parsing errors.
- Run a Fixnx scan and verify exposed Node.js endpoints are still reachable only as intended.
Related categories
Trusted references
FAQ
What is affected by CVE-2026-12590?
Express.js body-parser versions listed as affected should be reviewed: body-parser 1.x before 1.20.6, body-parser 2.x before 2.3.0.
What should I fix first?
Start with internet-facing sites, admin panels, login flows, plugins, themes, modules, packages, and systems that process user-controlled input or sensitive data.
How do I confirm the fix worked?
Apply the patched version or mitigation, clear caches where relevant, retest the affected workflow, and run a new Fixnx scan to verify public website exposure signals.
Why can this risk appear in multiple categories?
A vulnerability can belong to more than one platform or ecosystem. Fixnx keeps one canonical risk page while also listing it in every relevant category.