body‑parser 2.4.0 and 1.20.9 Fix CVE‑2026‑111181, a One‑Request Crash

How One Gzip Request Takes Down the Process #

body-parser decompresses request bodies by default. When a request carries a Content-Encoding such as gzip, it pipes the request into a decompression stream and, once the body is read, hands control to the next middleware while the request is still piped into that stream, with no error listener attached. The Express security post walks through the sequence: a valid gzip member followed by a zero byte and more data decodes normally, the application even sends its response, and then the trailing bytes reach the finished decoder. The decoder emits an error that nothing catches, and Node.js turns it into an uncaught exception that ends the process.

The post warns that a handful of such requests spread across nodes can take down a whole load-balanced cluster. Where the parser is mounted globally ahead of authentication, the request does not need a valid route or credentials. CISA's SSVC assessment of October 22 rates exploitation as none.

Affected and Fixed body-parser Versions, and the Express Path #

Most Express applications never import body-parser themselves; express.json() and express.urlencoded() come from it. A search for bodyParser.json in application code therefore misses them, and only the resolved dependency tree shows which version runs. Express 5.3.0, released on October 9, requires body-parser ^2.3.0, so even a fresh install of the newest Express could have resolved the vulnerable 2.3.0 until 2.4.0 appeared.

The same parser had an earlier, low-severity fix: CVE-2026-12590 (GHSA-v422-hmwv-36x6), fixed in 2.3.0 and 1.20.6, made an invalid limit value silently disable the size check. An application that jumps straight to 2.4.0 or 1.20.9 gets both fixes.

Updating body-parser in Express Projects #

1. Run npm ls body-parser and check every resolved copy against the table, including copies under other packages.
2. On Express 5.x or 4.22.x, run npm update body-parser and commit the updated lockfile, then rebuild and redeploy container images.
3. On Express 4.21.2 or older, upgrade Express to 4.22.x, or add an npm overrides entry that forces body-parser 1.20.9.
4. Until the update ships, set inflate: false on every body-parser or express.json() call in applications that do not need compressed request bodies; encoded requests are then rejected before a decompression stream exists.
5. Run the application under a process manager that restarts crashed workers, which limits the outage from a single request while the fix rolls out but does not prevent it.

npm ls body-parser express
npm update body-parser
grep -rnE "express\.(json|urlencoded|raw|text)\(|bodyParser\.|inflate" --include="*.js" --include="*.ts" --include="*.mjs" src/

Checking an Express Project for the Vulnerable Parser #

The first command above prints every resolved body-parser and the Express version that pulls it in; any 2.x below 2.4.0 or 1.x below 1.20.9 is exposed. The search lists the parser calls, so each one can get inflate: false as a stopgap where compressed bodies are not expected. Applications that never parse request bodies, for example ones that only serve static files, do not call the vulnerable code.