Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact A single request can crash any application using body-parser with default options. When a request carries a Content-Encoding (for example gzip), body-parser pipes it into a decompression stream and, after reading the body, leaves that stream piped with no error listener. A payload of one valid compressed frame followed by trailing bytes decodes and the application responds normally, but the trailing bytes then reach the already-finished decoder, which emits an error that is re-thrown as an uncaught exception and terminates the process. No authentication or matching route is required, since parsing runs before routing. Patches Fixed in body-parser 2.4.0 and 1.20.9. Upgrade to one of these versions. Workarounds Pass inflate: false to the body-parser middleware if the application does not need to accept compressed request bodies. This rejects encoded requests before any decompression stream is created.
Recommended action: Upgrade to 2.4.0 or 1.20.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When body-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. This issue affects applications that pass a programmatically computed or user-configurable value to the limit option without validating it first. Patches This issue is fixed in body-parser@2.3.0 and body-parser@1.20.6 via #698. After the fix, invalid limit values throw a clear error at parser construction time instead of silently disabling enforcement. null and undefined continue to fall back to the default limit (100kb). Workarounds Validate limit before passing it to body-parser. For example, parse the value with bytes.parse() at startup and reject any configuration where it returns null or a…
Recommended action: Upgrade to 2.3.0 or 1.20.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact body-parser 2.2.0 is vulnerable to denial of service due to inefficient handling of URL-encoded bodies with very large numbers of parameters. An attacker can send payloads containing thousands of parameters within the default 100KB request size limit, causing elevated CPU and memory usage. This can lead to service slowdown or partial outages under sustained malicious traffic. Patches This issue is addressed in version 2.2.1.
Recommended action: Upgrade to 2.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact body-parser <1.20.3 is vulnerable to denial of service when url encoding is enabled. A malicious actor using a specially crafted payload could flood the server with a large number of requests, resulting in denial of service. Patches this issue is patched in 1.20.3 References
Recommended action: Upgrade to 1.20.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.