TL;DR

Node2Shell is CVE-2026-111497, an out-of-bounds write in the Brotli decoder. Despite the name, the flaw originates in Google’s Brotli library rather than in Node.js code. The CVE is assigned by Google against Brotli, and Node.js is genuinely affected because it bundles that decoder and exposes it through node:zlib. Patch Node.js to 22.23.4, 24.22.1 or 26.12.1, released 21 October 2026. Node 20 and Node 25 are end-of-life and get no fix. Brotli itself is fixed in 1.0.10, 1.1.1 and 1.2.1, and the same flaw reaches Python’s brotli and brotlicffi packages and Bun. You are exposed only if your application decompresses Brotli data that an attacker can supply. On severity, Google scores it 9.2 Critical and Node.js rates it High. On exploitability, Imperva’s red team reported reproducing code execution against an official unpatched Node.js build on 22 October, taking multiple attempts, and confirmed the patched release rejected the same input. Other public analyses show crashes or dispute exploit reliability, so do not assume every exposed application is exploitable the same way.

Key Takeaways

  • CVE-2026-111497 originates in Brotli and affects Node.js through its bundled decoder. Both statements are true, and the second is why patching Node alone may not be enough.
  • Fixed Node.js versions: 22.23.4, 24.22.1, 26.12.1, all released 21 October 2026.
  • Node.js 20.x and 25.x are end-of-life and will not be patched. Migrate rather than wait.
  • Brotli is fixed in 1.0.10, 1.1.1 and 1.2.1. Python brotli in 1.2.1 and brotlicffi in 1.2.1.0. Bun 1.4.4 includes Brotli security fixes, though CVE-specific confirmation remains limited.
  • Google, as the assigning authority, scores it 9.2 Critical on CVSS 4.0. The Node.js project rates it High. Both are correct for what they are scoring.
  • Exposure requires your code to decompress attacker-supplied Brotli. Express 5 does this by default through express.json().
  • It was not in CISA’s Known Exploited Vulnerabilities catalog as of 23 October 2026.
  • Nine other CVEs shipped in the same Node.js release, including three further High-severity issues in DNS and TLS.

Prepared by the SearchEngineInfo editorial team. Details verified against the Node.js security advisory, the MITRE CVE record, the NVD entry, the GitHub advisory and the Brotli release notes. Checked 24 October 2026.

Fact Value
CVE CVE-2026-111497
Common name Node2Shell
Vulnerable component Brotli decoder (c/dec/decode.c)
Flaw type Out-of-bounds write (CWE-787), from an unchecked return value (CWE-252)
Google CVSS 4.0 9.2, Critical
Node.js severity High
Node.js 22 fixed in 22.23.4
Node.js 24 fixed in 24.22.1
Node.js 26 fixed in 26.12.1
Brotli fixed in 1.0.10, 1.1.1, 1.2.1
Security release date 21 October 2026
CVE published 22 October 2026

What is Node2Shell (CVE-2026-111497)?

Node2Shell is the informal name for CVE-2026-111497, an out-of-bounds write in the Brotli decompression library. It was published on 22 October 2026 and fixed in the Node.js security release of Wednesday, 21 October 2026.

The Node.js advisory describes the mechanism precisely, in two paragraphs:

“A flaw in the Brotli decoder bundled with Node.js allows malformed compressed input to write past the end of an internal decoder buffer.”

“An invalid block switch was reported as a temporary need for more input instead of a permanent format error, so the streaming decoder kept appending input bytes to an eight-byte internal buffer.”

In plain terms: the decoder met input it should have rejected outright, treated it as merely incomplete, and kept writing into a buffer eight bytes long. The consequence, per Node.js, is that an attacker who supplies Brotli data your application decompresses “can corrupt process memory, which can lead to a crash, disclosure of process memory, or remote code execution.”

The CVE record lists two weaknesses together, and the pairing tells the story: CWE-252, Unchecked Return Value, leading to CWE-787, Out-of-bounds Write. A return value that should have signalled a fatal format error was not checked, and the write went past the buffer.


Node2Shell originates in Brotli but also affects Node.js

Both halves of that heading matter. The defect is in Google’s Brotli decompression library. Node.js is genuinely vulnerable too, because it bundles that decoder and exposes it through node:zlib, which is why the Node.js project issued its own advisory and its own patched releases.

What the CVE record adds is where the defect lives, and that changes who else needs to act.

Field Value in the CVE record
Assigning authority Google
Official title Out-of-Bounds Write in Google Brotli Decoder
Vendor Google
Product Brotli
Affected versions 1.0.3 up to but not including 1.0.10; 1.1.0 up to but not including 1.1.1; 1.2.0 up to but not including 1.2.1. The three named releases are the fixes, not vulnerable versions.
Flaw location c/dec/decode.c

Node.js appears nowhere in that record, because the record describes the upstream library. The Node.js advisory documents the downstream impact separately. The same library sits underneath a great deal of other software, which is why the GitHub advisory is titled “Brotli: Out-of-bounds write in the Brotli decoder (‘Node2Shell’) also affects the PyPI Brotli package.”

Why this matters practically: if you patch Node.js and stop there, you may still be running the vulnerable library elsewhere. Python services, Bun runtimes, and anything linking a system Brotli package all need checking separately. Patching Node fixes Node’s bundled copy, nothing more.


Why the severity ratings disagree

You will see this called both High and Critical. Both are accurate, because they score different things.

Source Rating What it is rating
Google (CVE assigner) 9.2 Critical, CVSS 4.0 The Brotli library flaw in the abstract, assuming an attacker who can reach a vulnerable decoder
GitHub Advisory Critical, 9.2 Mirrors the CVE record
Node.js project High The flaw as reachable through Node.js, where exploitation depends on the application decompressing attacker-controlled input

The full CVSS 4.0 vector is CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Two parts of that are worth reading rather than skipping. PR:N and UI:N mean no privileges and no user interaction are required. AT:P means the attack requires certain conditions to be present, which is the scoring system acknowledging that this does not fire everywhere unconditionally.


What is affected

Node.js

Line Status Fixed in Action
Node.js 26.x Current 26.12.1 Upgrade
Node.js 24.x LTS 24.22.1 Upgrade
Node.js 22.x LTS 22.23.4 Upgrade
Node.js 25.x End-of-life since 31 March 2026 No fix Migrate to 24.x or 26.x
Node.js 20.x and earlier End-of-life since 24 March 2026 No fix Migrate to a supported line

End-of-life lines are the trap here. They received no fix in this release, and Node.js advises treating unsupported versions as affected whenever a security update ships. Upgrading the minor version on 20.x or 25.x achieves nothing, because there is no patched minor version to move to. Whether a given old build is exploitable depends on the bundled decoder version and whether attacker-controlled Brotli reaches it, but the remedy is the same either way: migrate to a supported line.

Brotli and everything else downstream

Component Affected versions Fixed in
Google Brotli (C library) >=1.0.3, <1.0.10; >=1.1.0, <1.1.1; >=1.2.0, <1.2.1 1.0.10, 1.1.1, 1.2.1, all released 21 October 2026
Python brotli (PyPI) >= 1.0.3, < 1.2.1 1.2.1
Python brotlicffi (PyPI) >= 1.0.3, < 1.2.1.0 1.2.1.0
Bun Reported as 1.4.3 and earlier 1.4.4, 22 October 2026. Brotli security updates reported; direct CVE mapping not confirmed.
Linux distribution packages Varies by distribution Depends on each distribution’s own update

That last row deserves attention. Node.js carries its own bundled Brotli and received a cherry-picked fix. Software that links the system Brotli library instead depends on your distribution shipping a patched package, on its own schedule.


Are you actually exposed?

Having a vulnerable version installed is not the same as being reachable. The flaw needs attacker-controlled Brotli data to pass through a decoder in your process.

Check for these paths:

Express with express.json(), where body-parser 2.x is in use. That version’s documentation states the JSON parser “supports automatic inflation of gzip, br (brotli) and deflate encodings,” with inflate defaulting to true. Imperva’s testing covered Express 5.0.0 to 5.3.0 with body-parser 2.0.0 to 2.3.0 specifically. The parser still only handles requests matching its content-type and middleware configuration, so it does not decompress everything arriving at your server. Check which body-parser version your install resolves to rather than inferring from the Express major version.

Direct node:zlib use. Search your codebase for createBrotliDecompress, brotliDecompress and brotliDecompressSync.

Server-side fetch() to servers you do not control. Imperva’s tests covered Node’s built-in fetch() on consumed responses. Whether this is a live path for you depends on your runtime, whether the response actually arrives Brotli-encoded, and whether an attacker can influence what that upstream returns. A compromised or hostile upstream is the realistic scenario.

Anything accepting uploads or webhooks where a client sets the content encoding.

Field check: Container images are the common miss. Rebuilding is not optional, because a base image tag such as node:24-alpine may still resolve to a pre-patch build in your local cache or registry mirror. Pull fresh, rebuild, and verify with node -v inside the running container rather than on your build machine.


How to resolve it

1. Upgrade Node.js. Move to 22.23.4, 24.22.1 or 26.12.1. If you are on an end-of-life line, this is a migration rather than an upgrade, and it is now urgent for reasons beyond this one CVE.

2. Rebuild and redeploy container images. Patching the host does nothing for a container carrying its own Node binary.

3. Patch the other runtimes. Python brotli to 1.2.1 and brotlicffi to 1.2.1.0, both named directly in the GitHub advisory. For Bun, update to a release containing the relevant Brotli security fix and verify CVE-specific applicability against Bun’s own guidance, since 1.4.4’s notes list Brotli without naming this CVE. Check your distribution for a system Brotli update.

4. Audit your Brotli decode paths using the list in the previous section, so you know what your actual exposure was.

5. If you cannot patch immediately, these reduce exposure without replacing the fix:

  • Reject Content-Encoding: br on inbound requests at your CDN, load balancer or reverse proxy.
  • Set inflate: false in Express body parsing. Note that this rejects gzip as well, so it may break legitimate clients.
  • Run Node.js as an unprivileged user, with as few secrets in its environment as the application can tolerate.

A WAF rule is a layer, not a substitute. Treat all of these as temporary.

Working out what you are running

These are inventory checks, not exploit tests. They tell you what versions are present and where Brotli decoding happens in your own code. In order, they report the Node.js version in the current environment, any direct Brotli decode calls in your source, which Express and body-parser versions actually resolve, the installed Python Brotli packages, and the Bun version where Bun is installed.

node --version
grep -RInE 'createBrotliDecompress|brotliDecompress' ./src
npm ls express body-parser
python -m pip show brotli brotlicffi
bun --version

A clean result here does not prove you are safe. Transitive dependencies, container images, other languages in the stack, and decode paths outside ./src can all still carry a vulnerable decoder. Run node --version inside the running container, not on the machine that built it.

A caution worth stating: remediate from vendor advisories and trusted package sources. Patch from nodejs.org and your package manager, and treat unverified exploit demonstrations and third-party scanners offered around a named vulnerability with caution.


Is it being exploited, and is it really RCE?

The honest answer is that the picture is contested, and anyone telling you otherwise is ahead of the evidence.

What is established. The memory corruption is real and the patch is real. Google scores the theoretical impact at 9.2. Node.js describes outcomes including crash, memory disclosure and remote code execution.

The strongest evidence so far. Imperva’s red team published an account on 22 October 2026 describing code execution through this flaw. Their report states that “code carried in that data had run inside the target process,” evidenced by a test application with no file-creation logic producing a marker file after receiving Brotli input. They used the official Node.js 24.22.0 Linux arm64 image in fresh containers, with no debugger or instrumented binary, and tested both Node’s built-in fetch() on consumed responses and Express 5.0.0 to 5.3.0 with body-parser 2.0.0 to 2.3.0 on request bodies.

Two caveats come from Imperva themselves. Execution “took multiple attempts in our setup” and “did not succeed on every attempt.” They tested those configurations, not every Node.js build or application. Critically, Node.js 24.22.1 rejected the same inputs and no marker file appeared, which is direct confirmation that the patch works.

What other public analysis shows. Less consistency. As summarized in Brandefense’s roundup of public proof-of-concept work, one analysis crashes unpatched Node.js without claiming code execution, another reports local code execution only under specific conditions including an unpatched system Brotli library and a predictable memory layout, and a third argues the realistic impact is denial of service. We have read that summary rather than each underlying analysis, so treat the characterization as second-hand. The takeaway holds either way: reliable exploitation from publicly available code is still disputed, even though Imperva’s controlled reproduction is not.

Exploitation in the wild. As of 23 October 2026, CVE-2026-111497 was not listed in CISA’s Known Exploited Vulnerabilities catalog.

None of this is a reason to delay patching. A reliable crash in a decoder reachable from the network is serious on its own, and the gap between “crash” and “code execution” has a habit of closing. It is a reason to describe the risk accurately when you escalate it internally.


The nine other CVEs in the same release

Node2Shell got the name and the attention. The 21 October release fixed ten issues, and three others are also rated High.

CVE Severity Issue
CVE-2026-111497 High / Critical Brotli decoder out-of-bounds write (Node2Shell)
CVE-2026-105482 High dns.resolve truncates names containing a NUL character
CVE-2026-105483 High TLS certificate hostname bypass when the IP is written in fullwidth digits
CVE-2026-106069 High TLS certificate hostname bypass when the host loosely resolves to an IP address
CVE-2026-105481 Medium Keep-alive socket processes a response written before the request was sent
CVE-2026-106072 Medium Improper certificate validation for non-canonical IPv4 hostnames
CVE-2026-106074 Medium crypto.randomUUID() and randomInt() entropy caches saved into startup snapshots
CVE-2026-106070 Low ZipFile returns attacker-controlled prefix bytes after failed header validation
CVE-2026-106071 Low Permission Model filesystem over-grant via wildcard radix lookup
CVE-2026-106073 Low Permission Model bypass with fs.realpathSync

Two of those TLS issues allow certificate hostname validation to be bypassed. If your threat model includes machine-in-the-middle, they may matter to you more than the Brotli flaw does.

The Brotli fix was reported by OpenAI Codex Security, credited to Khai Tran and Sylvie Mayer, and fixed by Node.js maintainers Matteo Collina and Antoine du Hamel.


Keeping your site visible while you patch

If patching means downtime, the SEO handling is the same as for any emergency maintenance window, and we covered it in detail when PHP2Shell prompted the same question.

The short version: for a short maintenance window, return HTTP 503 with a Retry-After header rather than a 200 serving an error page, a 404, or a redirect to a holding page. A 503 tells Googlebot the outage is temporary. Keep robots.txt reachable while you do it, and restore normal responses promptly, because a 503 sustained over days can still affect crawling and indexing. It buys you a window, not indefinite cover.


Limits of this article

This is a developing situation. Everything here reflects the position on 24 October 2026, three days after the fix shipped. Exploitation status in particular can change quickly.

We have not independently tested exploitability. The claims about what proof-of-concept code does are reported from published analyses, and those analyses disagree with each other.

Distribution package status varies and moves. Check your own distribution’s security tracker rather than relying on a snapshot here.

Bun’s fix is listed but not explicitly tied to this CVE. Bun 1.4.4 shipped on 22 October 2026, and its release notes do list Brotli among the components receiving security fixes, alongside TLS, HTTP/1.1, HTTP/2, HTTP/3 and WebSocket. The notes do not name CVE-2026-111497. Treat 1.4.4 as the version to be on, and check Bun’s own security notes before recording it as a confirmed fix for this specific CVE.

NVD has the entry but has not finished analyzing it. As of 24 October 2026 the record is published with a status of “Awaiting Analysis,” carrying only Google’s own CVSS score. Version and remediation details here come from the MITRE CVE record, the Node.js advisory, the GitHub advisory and Brotli’s release notes, which are the upstream sources NVD will itself draw on.


Frequently Asked Questions

What is CVE-2026-111497?

An out-of-bounds write in the Brotli decompression library, published 22 October 2026 and nicknamed Node2Shell. A crafted Brotli stream can write past an eight-byte internal buffer, corrupting memory. Google scores it 9.2 Critical on CVSS 4.0. It reached public attention through Node.js, which bundles Brotli, but the CVE is recorded against Google’s Brotli library.

Does Node.js have vulnerabilities?

Yes, like any runtime. The 21 October 2026 release alone fixed ten, including four rated High. Node.js publishes them through its security release process, usually in batches, with advisories at nodejs.org. The practical response is to track the security blog, stay on a supported line, and treat end-of-life versions as permanently unpatched.

Which Node.js versions are affected by Node2Shell?

Node.js 22.x, 24.x and 26.x before 22.23.4, 24.22.1 and 26.12.1. Node.js 20.x and 25.x are end-of-life, received no fix, and remain vulnerable. Upgrade the supported lines; migrate off the others.

What is CVE-2026-109618?

A different vulnerability. It is one of two critical remote code execution flaws in PHP, alongside CVE-2026-109619, known together as PHP2Shell. It has nothing to do with Brotli or Node.js beyond arriving in the same month. We covered it, and the HTTP 503 maintenance handling it prompted, in our PHP2Shell article.

Is PHP 7.4 vulnerable?

PHP 7.4 reached end of life in November 2022 and no longer receives upstream security updates, so it may contain unresolved vulnerabilities. Some Linux distributions backport selected fixes into their own packages, so the exact position depends on where your PHP came from. The appropriate remediation is migrating to a supported PHP release rather than relying on an unsupported one.

Is Node2Shell being exploited in the wild?

As of 23 October 2026, CVE-2026-111497 was not listed in CISA’s Known Exploited Vulnerabilities catalog. Read that for what it is: KEV records exploitation CISA has confirmed, so absence from it is not evidence that exploitation has never occurred. Separately, Imperva reported reproducing code execution in controlled testing on 22 October, taking several attempts, and confirmed the patched release rejected the same input. Public proof-of-concept code is less consistent. Patch regardless.

What are the top 5 CVE vulnerabilities?

There is no fixed list, because it depends on what you run. The useful version of this question is which vulnerabilities are known to be exploited, and the authoritative answer is CISA’s Known Exploited Vulnerabilities catalog rather than any ranking by severity score. A 9.8 in software you do not run matters less than a 6.5 in software exposed on your edge.

Can Node2Shell be exploited without authentication?

The CVSS vector says no privileges and no user interaction are required (PR:N/UI:N), so authentication is not a barrier in principle. What is required is that attacker-supplied Brotli data reaches a vulnerable decoder in your process. If an unauthenticated endpoint accepts compressed request bodies, that condition is met. The vector also carries AT:P, meaning further conditions must hold for an attack to succeed, which matches Imperva reporting that their reproduction took several attempts.

Does Express automatically decompress Brotli request bodies?

Where body-parser 2.x is in use, its JSON parser supports automatic inflation of gzip, Brotli and deflate, and the inflate option defaults to true. So you do not have to opt in. It still only processes requests matching its configured content type, so it is not decompressing everything that arrives. Check the resolved body-parser version with npm ls body-parser rather than inferring it from your Express major version.

If I patch Node.js, am I safe?

From Node’s bundled Brotli, yes. The same flaw affects Python’s brotli and brotlicffi packages, Bun, and anything linking a vulnerable system Brotli library. Patching Node fixes Node.


Sources and References

Primary sources

Original research

Secondary analysis

Related reading on this site

ⓘ Key Takeaways

Node2Shell is an out-of-bounds write in the Brotli decoder, recorded against Google's Brotli library rather than Node.js. Patch Node.js to 22.23.4, 24.22.1 or 26.12.1, and check Python, Bun and system Brotli separately.

Chitranshu Sharma

Chitranshu Sharma

SEO Strategist & Founder at SearchEngineInfo

Chitranshu Sharma is a digital marketing strategist with 8+ years of experience in SEO, paid media, and content strategy. He has helped brands scale organic traffic from zero to hundreds of thousands of monthly visitors. He writes about search engine optimization, AI-powered search, and data-driven content strategy.