body‑parser 2.4.0 and 1.20.9: Fixes Crash From Compressed Bodies

body-parser 2.4.0 and 1.20.9 Fix the Compressed-Body Crash #

body-parser accepts compressed requests by default, and the Express.js advisory says this renders most unpatched versions vulnerable. With inflate enabled, the contentstream() function creates a decompression stream and pipes the incoming request into it. When the body is read, body-parser calls next() on the success path while the request is still piped into that decoder, and no error listener is attached to the stream. The request is handed on while the decoder is still open.

A payload containing a valid gzip member, a zero byte and trailing data triggers the failure. The decoder reaches the end of the first member and signals completion but does not close. raw-body returns the decoded payload and detaches its event listeners, including the error listener. The trailing bytes then reach the finished decoder, which emits an error. The only handler left is the one pipe() installed, which re-emits the error, so Node raises an uncaught exception and the process crashes. By then the application has already received the request and sent a normal response.

"The trailing bytes continue flowing into the still-open decoder, which emits an error because decompression has already finished." Express.js advisory

The advisory includes a minimal reproduction on a raw node:http server and states that a standard Express 4 or 5 application behaves the same way. Any server running an impacted version with request decompression enabled is therefore vulnerable, and the inflate option on each parser call controls whether that path is open.

Global Parser Placement Widens Who Can Reach the Crash #

A valid route or authentication check is not required. The advisory states that when the parser is mounted globally ahead of authentication, the request does not need to match a valid route or pass an authentication check. A remote client can crash the application with one request, and the advisory adds that spreading a handful of requests across vulnerable nodes can take down an entire load-balanced cluster.

In practice, an app.use() call that registers the parser before authentication middleware exposes the crash path to unauthenticated requests on any route. Checking where each parser is registered is therefore part of the review described below.

Express 5.3.0 Raises body-parser to ^2.3.0 for a Fail-Open Limit Fix #

The Express 5.3.0 release notes, dated October 9, 2026, upgrade body-parser to ^2.3.0 to fix CVE-2026-12590 (GHSA-v422-hmwv-36x6). An invalid limit option value silently disabled request body size enforcement, which allowed denial of service through arbitrarily large payloads. Invalid limit values now throw at parser initialization instead of being ignored.

Limit Validation Moves to Parser Initialization #

For a bad limit value, the outcome changes from an unenforced size cap to an error at startup. The ^2.3.0 range also permits 2.3.0, which the body-parser advisory lists as vulnerable to CVE-2026-111181. This suggests that a project on Express 5.3.0 can still resolve body-parser 2.3.0, so the resolved version in the lockfile should be checked rather than assumed to be fixed.

Dependency Fixes Reaching Apps Through Express #

Express 5.3.0 upgrades qs to ^6.16.0, which fixes CVE-2026-2391, CVE-2026-82417 and CVE-2026-82562: arrayLimit bypasses in comma parsing and a denial of service via an attacker-controlled isBuffer. The same release upgrades proxy-addr to ^2.0.8 for CVE-2026-90711, the Critical issue described below. These packages arrive through Express's dependency tree, so this suggests that the qs and proxy-addr entries in package-lock.json show whether a project already resolves the fixed versions.

Response Header and Content-Type Behaviour Changes #

Two changes in the 5.3.0 notes are not security fixes and alter response output. The content-type upgrade to ^2.0.0 brings a faster parser, described as about 1.5x quicker Content-Type parsing and formatting in res.send(). It also keeps existing parameters when adding the charset, so text/plain; foo=bar becomes Content-Type: text/plain; foo=bar; charset=utf-8, and res.send() no longer throws on a Content-Type that fails to parse. The content-disposition upgrade to ^2.0.1 drops quotes from token filenames, so res.attachment('user.html') now emits filename=user.html. Applications that assert the exact header bytes need updated expectations.

Multipart Upload Services Need multiparty 4.3.1 or multer 2.4.0 #

The September 2026 Security Releases, dated September 30, 2026, cover two multipart parsers. multiparty 4.3.1 and multer 2.4.0 are the fixed versions. multiparty versions >= 2.1.0 and < 4.3.1 are affected by CVE-2026-87908 (High), a denial of service through unbounded part-header accumulation. multiparty bounded field values and uploaded file bytes but not the size of an individual part header, so a part header that never terminates grows server memory until the process crashes, even when every documented limit is configured. The fix in 4.3.1 adds a maxHeadersSize option, defaulting to 16 KB. Any service accepting multipart uploads through multiparty is affected.

multer versions >= 2.2.0 and < 2.4.0 are affected by CVE-2026-88932 (Medium). The impact is denial of service through orphaned disk writes: an unauthenticated attacker sending aborted requests to any route backed by disk storage could accumulate orphaned files until the upload directory or the shared system temporary directory was exhausted. The cleanup covered only in-flight uploads that already had a path, so an upload aborted before the storage engine assigned that path was written to disk with nothing to remove it. The fix in 2.4.0 cleans up files aborted within this window.

compression 1.8.2 Destroys Streams for Aborted Responses #

compression versions < 1.8.2 are affected by CVE-2026-87776 (High), a denial of service through a memory leak on prematurely closed responses. When a client disconnected before a compressed response finished, the zlib stream was never destroyed, so each aborted response kept its native zlib memory. A remote client that repeatedly opens requests and aborts them mid-response can grow server memory until the process runs out of memory. The September release states that all applications using compression are affected, and the fix in 1.8.2 destroys the compression stream when the response closes early.

hbs 4.3.1 Turns an Async Helper Crash Into a Render Error #

Only hbs 4.3.0 is affected by CVE-2026-87123 (Medium). hbs 4.3.0 could crash the Node.js process when an async helper registered with registerAsyncHelper resolved to an object with a truthy but non-callable toHTML property. Output escaping calls value.toHTML(), and because the async substitution runs on a later tick outside the render function's try/catch, the throw became an uncaught exception. No response was sent and the Express error handler could not intercept it. Objects parsed from untrusted JSON, such as {"toHTML":"x"}, have exactly this shape, so applications whose async helpers can resolve to externally influenced objects are in scope. The fix in 4.3.1 handles the throw as a normal render error.

morgan 1.12.1 and cookies 0.9.2 Stop Request Data From Breaking Logs and Cookies #

morgan versions < 1.12.1 and cookies versions < 0.9.2 are affected by two Medium issues. For morgan, CVE-2026-87859 is log injection: field escaping handled control characters and Unicode line separators but not the double quote, which delimits the quoted fields of the Apache combined log format. A user-agent, referrer or request header containing a double quote could close a field early, so a log consumer that parses by field position would read attacker-supplied text as the next field. The fix in 1.12.1 escapes the double quote as well.

For cookies, CVE-2026-88038 is Set-Cookie attribute injection. The domain and path options were checked only against a permissive matcher that allows ;, and both were written into the header unescaped. An application that passes request-derived data into them, such as domain: '.' + req.headers.host, lets that value override SameSite, Secure, HttpOnly or Domain on the cookies it issues. The fix in 0.9.2 validates both options against the stricter RFC 6265 character sets.

proxy-addr 2.0.8 Fixes IPv4-Mapped Trust Subnets Behind a Proxy #

CVE-2026-90711 (Critical) affects proxy-addr versions >= 1.1.0 and < 2.0.8. proxy-addr decides which hops to trust so that Express believes the X-Forwarded-For header when setting req.ip and req.ips. When a trusted proxy subnet was written as an IPv4-mapped IPv6 address with a short prefix, such as ::ffff:10.0.0.0/8, the subnet matched every address. Every unauthenticated client was then trusted as a proxy, so req.ip could be set to any value, defeating IP-based access control, rate limiting, geolocation and audit logging. The fix in 2.0.8 matches an IPv4 address against an IPv6 trust subnet only when that subnet genuinely covers the IPv4-mapped range.

Also in this release #

Express 5.3.0 is the release that lists these changes.

• res.send(): Content-Length is added only when no Transfer-Encoding header is present (#4893), and ETag generation is unaffected by Transfer-Encoding (#7459).
• req.fresh checks QUERY requests, so a matching validator returns 304 Not Modified (#7366).
• res.redirect() HTML responses include DOCTYPE, title and body tags (#5167), and app.render accepts null options (#6903).
• The default error handler logs the full error object, including Error.cause and library properties (#6464).
• String responses without an explicit Content-Type no longer have their Content-Type processed twice in res.send() (#6991).
• Maintenance: staged npm publication with dist-tag support (#7464) and a Node.js v26 CI build (#7218).
• Full list: Express 5.3.0 release notes.

Upgrade checklist #

Upgrade body-parser first, to 2.4.0 or 1.20.9, because the September package command does not include it.

1. Open package-lock.json, find the body-parser entry, and compare its resolved version with 2.0.0 through 2.3.0 and with 1.20.8 and earlier.
2. Upgrade body-parser to 2.4.0 or later, or to 1.20.9 or later.
3. Update the September packages with the command below.
4. On Express 5.3.0, confirm that the resolved body-parser is 2.4.0 or later, because the ^2.3.0 range also permits 2.3.0.
5. If the application does not need compressed request bodies, set inflate to false. The advisory warns that this rejects compressed bodies.
6. Review every body-parser limit option, because invalid values now throw at parser initialization.

npm update compression cookies hbs morgan multer multiparty proxy-addr

import bodyParser from 'body-parser';
app.use(bodyParser.json({ inflate: false }));

Checking body-parser Versions and the inflate Option in Your App #

Search package-lock.json for the body-parser entry and read its resolved version. A value from 2.0.0 through 2.3.0, or 1.20.8 or earlier, falls in the advisory's vulnerable range. Then search your source for bodyParser.json and other parser calls. A call without an inflate option accepts compressed bodies, and a call with inflate: false rejects them. Read the limit value in the same call, since an invalid one now stops startup.

Next, check where each parser is registered with app.use(). A parser registered ahead of authentication middleware is the placement the advisory describes, where the request does not need to match a route or pass an authentication check.