BREAKING: One gzipped POST crashes Express via body-parser CVE-2026-111181. Upgrade to 1.20.9 or 2.4.0

Send Express one request with a valid gzip body and a few trailing bytes after it, and the Node process dies. body-parser finishes reading the body, then leaves the decompression stream piped with no error listener. The leftover bytes hit a decoder that already closed; Node turns that into an uncaught exception and exits. No login, no matching route. Parsing runs before routing, so anything that mounts express.json(), express.urlencoded(), express.text() or express.raw() with the default inflate setting is exposed. The Express team published the fix today as CVE-2026-111181 / GHSA-27r3-jxmh-p828 and rates it high (CVSS 7.5, availability only).

body-parser sits under roughly 88 million weekly npm downloads. Express 4 and Express 5 both pull it in by default. This is our operator read of the advisory, the 1.20.9 / 2.4.0 release notes and the lib/read.js patch.

How to fix

Upgrade body-parser. Express itself has not shipped a new release that bumps the dependency yet, so bump the package directly and refresh the lockfile.

# Express 5 / body-parser 2.x
npm install [email protected]

# Express 4 / body-parser 1.x
npm install [email protected]

# Confirm what actually resolves
npm ls body-parser

One operator check

Look at the resolved version in the tree that actually runs, not the range in package.json:

npm ls body-parser
# vulnerable examples: [email protected], [email protected]
# patched:            [email protected], [email protected]

Run it inside the container or CI image you ship. A laptop on 2.4.0 says nothing about a Docker layer that froze package-lock.json in September. If you cannot redeploy today, pass { inflate: false } to every body-parser middleware you mount. That rejects Content-Encoding before any decompression stream is created.

app.use(express.json({ inflate: false }));
app.use(express.urlencoded({ extended: true, inflate: false }));

What the patch changed

The crash is not in gzip itself. After getBody returns, the old code left the decoder piped to req. On Node 11 and later, zlib ends the readable side of a decompression stream as soon as the compressed frame completes (Z_STREAM_END). Trailing bytes that arrive after that finish then emit an error on a stream with no listener, and Node kills the process. The advisory's PoC shape is one valid deflate or gzip frame of {"a":1}, plus a zero byte, plus a kilobyte of padding, sent with a matching Content-Encoding and a Content-Length that covers the whole thing.

The fix in lib/read.js does three things: it checks charset support before creating the decompression stream (so a 415 cannot leave a half-wired decoder), it unpipes and destroys the stream once the body is read, and it calls req.resume() so leftover bytes are drained instead of erroring. The same change landed on both the 1.x and 2.x lines.

Who is not in scope

• Apps that already pass inflate: false. Compressed bodies are rejected with 415 before a decoder exists.
• Stacks that never mount body-parser. Raw http.createServer handlers, Fastify, Koa and Hono are not this package. They have their own body parsers with their own bug history.
• Browsers and front-end bundles. body-parser is a Node middleware.
• Request bodies with no Content-Encoding. The decoder is only created when the request claims gzip, deflate or (on 2.x) Brotli.

What this is not

It is not remote code execution and it is not a data leak. The impact is availability: one unauthenticated request can take the process down. It is not in the CISA KEV catalog as of publication, and no in-the-wild campaign has been reported. Treat it as a same-day patch for any internet-facing Express service, not as a "wait for NVD" bug. CVSS 7.5 here means network, low complexity, no privileges, no user interaction, high availability impact, nothing for confidentiality or integrity.

Same-day sibling: multer CVE-2026-113872

The Express upload middleware shipped its own high-severity DoS the same morning. GHSA-q7qp-rjg7-q26m / CVE-2026-113872: when multer uses an asynchronous fileFilter, aborting a request while another file's filter is still pending resumes a stream multer already tore down. busboy then emits an unhandled error and the process exits. Fixed in multer 2.5.0. Synchronous fileFilter (or no filter) is not affected. Upgrade with npm install [email protected], or switch the filter to sync until you can. This is a different package and a different upgrade; do not assume a body-parser bump covers uploads.

Where HOL Guard fits

HOL Guard pauses risky actions by AI coding agents on developer machines. It does not patch body-parser or filter compressed request bodies, so the fix is still the upgrade. We track sources, timeline and scope for this issue on the HOL Guard security campaign page for CVE-2026-111181.

References

• GHSA-27r3-jxmh-p828: body-parser trailing bytes after compressed body
• body-parser 2.4.0 release, 1.20.9 release
• GHSA-q7qp-rjg7-q26m: multer async fileFilter DoS, multer 2.5.0
• CVE-2026-111181, CVE-2026-113872