A critical vulnerability in Google’s Brotli decompression library is drawing increasing attention from attackers, with exploitation attempts observed just days after patches became available.
Tracked as CVE-2026-111497 and commonly known as Node2Shell, the flaw allows specially crafted compressed data to corrupt application memory, potentially resulting in remote code execution (RCE). It carries a CVSS v4.0 score of 9.2 (Critical), although the Node.js project classifies the issue as high severity.
What Is Node2Shell (CVE-2026-111497)?
Node2Shell is an out-of-bounds write vulnerability in the Brotli decoder, a native compression component maintained by Google and used by numerous applications and software frameworks.
Brotli is widely used to compress web content, reducing bandwidth consumption and improving loading performance. Applications can also use Brotli to decompress HTTP request bodies, server responses, files, and other data.
The vulnerability originates in how the decoder processes malformed compressed streams. According to the official Node.js security advisory, a specially crafted Brotli stream can trigger an invalid block switch during decompression.
Under normal conditions, the decoder should recognize this as a permanent format error and reject the input. Instead, the vulnerable implementation incorrectly interprets the condition as a temporary need for additional data.
As processing continues, the streaming decoder repeatedly appends bytes to an internal eight-byte buffer without correctly clearing the invalid state. Eventually, these writes extend beyond the buffer’s allocated boundaries, corrupting adjacent process memory.
Depending on the application, memory layout, and runtime environment, this corruption can produce several outcomes:
- Remote code execution: Attackers may gain the ability to execute arbitrary instructions with the privileges of the affected process.
- Denial of service: Malformed compressed data can crash applications or cause decompression operations to stall.
- Information disclosure: Memory corruption may expose sensitive process data, potentially including credentials or other secrets.
The underlying weaknesses are associated with CWE-252 (Unchecked Return Value) and CWE-787 (Out-of-Bounds Write).
The upstream fix changes how the decoder handles the invalid block transition. Instead of continuing to process malformed data, patched implementations return a dedicated error, BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH.
Importantly, Node2Shell is not a vulnerability in the HTTP/2 protocol, despite the alternative name HTTP2Shell. The flaw exists in the Brotli decoder itself and can be triggered wherever affected software processes attacker-controlled compressed data.
How Attackers Can Exploit Node2Shell
A major concern surrounding Node2Shell is that applications do not need to invoke the vulnerable Brotli library directly to become exposed.
Many frameworks automatically decompress HTTP content, potentially providing attackers with a route into the vulnerable decoder.
Incoming HTTP requests
One attack scenario involves an attacker sending a malicious HTTP request containing a Brotli-compressed body.
The request includes the Content-Encoding: br header, indicating that the body is Brotli-compressed. If the application automatically decompresses the incoming content using a vulnerable implementation, the malicious stream can reach the decoder.
This exposure path has been demonstrated in Express 5 applications using affected Node.js versions.
Express 5 and body-parser 2.x support Brotli decompression in their request-body parsers. When decompression is enabled, including through the default inflate: true setting, an attacker-controlled request may reach the underlying decoder without the developer explicitly calling a Brotli API.
A basic Node.js HTTP server does not automatically decompress incoming Brotli bodies. Exposure therefore depends on application code, middleware, or another component performing decompression.
Malicious HTTP responses
Node2Shell can also affect applications acting as HTTP clients.
Node.js’s built-in fetch() API can automatically decompress Brotli-encoded responses. If an application retrieves content from an attacker-controlled or compromised server, the returned compressed data may trigger the vulnerability.
This introduces risks for services that retrieve external resources, process webhooks, import remote content, or otherwise consume responses from untrusted endpoints.
An attacker does not necessarily need direct access to an application’s public HTTP interface. Control over content that the application subsequently decompresses may be sufficient.
Other data-processing workflows
The same vulnerability can potentially be reached through file processing and native library integrations.
The affected decoder can be reached through JPEG XL metadata processed by FFmpeg and its libjxl dependency. Testing has demonstrated memory corruption and instruction-pointer control through that path, although complete remote code execution has not been established.
A remotely triggered denial-of-service condition in ClickHouse through a crafted Brotli-compressed HTTP request body was also reproduced.
These findings illustrate why organizations should not limit their assessment to internet-facing Node.js servers. Software that processes compressed documents, images, API responses, or other untrusted data may also be exposed.
Node2Shell Exploitation Observed in the Wild
On October 21, 2026, Node.js released patches for its supported release lines. By the following day, working proof-of-concept attacks had demonstrated code execution against the official Node.js 24.22.0 Linux ARM64 image.
The exploits delivered code through malicious Brotli request and response bodies, using an unmodified production build rather than an artificially weakened or instrumented binary.
The same payloads were rejected by the patched Node.js 24.22.1 release.
Remote code execution was also reproduced on x86-64 systems, including applications built with Express 5.3.0, Koa 3, and Node.js’s HTTP and decompression APIs.
On October 27, CISA added the vulnerability to its KEV catalog, establishing that the issue should be treated as actively exploited.
Affected Software and Fixed Versions
The vulnerability affects Google Brotli versions 1.0.3 through 1.2.0, excluding the subsequently patched maintenance releases.
Because Brotli is bundled or linked by numerous projects, the affected software extends beyond Node.js.
| Software or component | Affected versions | Fixed versions |
| Node.js 22.x | Before 22.23.4 | 22.23.4 |
| Node.js 24.x | Before 24.22.1 | 24.22.1 |
| Node.js 26.x | Before 26.12.1 | 26.12.1 |
| Google Brotli | 1.0.3–1.0.9, 1.1.0, 1.2.0 | 1.0.10, 1.1.1, 1.2.1 |
| Bun | 1.0.21 through 1.4.3 | 1.4.4 |
| Python Brotli | Vulnerable releases through 1.2.0 | 1.2.1 |
| Python brotlicffi | Vulnerable releases through 1.2.0.2 | 1.2.1.0 |
| .NET 8 / 9 / 10 | Before 8.0.33 / 9.0.22 / 10.0.14 | 8.0.33 / 9.0.22 / 10.0.14 |
Node.js releases that have reached end of life, including 20.x, 23.x, and 25.x, do not receive upstream security fixes for this issue. Organizations should migrate affected deployments to supported, patched releases.
The listed versions reflect upstream or vendor fixes. Linux distributions may also backport security patches into packages that retain older version numbers, making vendor advisories and package changelogs essential when assessing remediation status.
For example, patched packages are available for Debian 12 and 13, while other distributions have different release schedules and remediation requirements.
Enterprise Products Are Also Affected
The breadth of the vulnerability became clearer as major vendors began publishing their own impact assessments.
Palo Alto Networks confirmed that certain PAN-OS configurations are affected when Brotli inspection and TLS/SSL decryption are enabled on the firewall dataplane. The company stated that the management interface is not affected and published product-specific fixes and temporary mitigations.
Broadcom also disclosed exposure in VMware Cloud Foundation’s SDDC Manager, where the vulnerability may enable code execution under applicable network-access conditions. The vendor published workarounds while remediation remained pending for affected versions.
These disclosures highlight a broader challenge: organizations may be exposed through commercial appliances, infrastructure software, or managed services even when they do not operate an obvious Node.js application.
Security teams should consult the Palo Alto Networks advisory and Broadcom security bulletin VMSA-2026-0008 for applicable product-specific guidance.
Published Indicators of Compromise
The following indicators were reported in connection with October 26 exploitation attempts and reconnaissance activity:
| Indicator | Value | Context |
| Source IP | 94.154.43.7 | Observed exploitation-attempt source |
| SHA-256 | 7fcbdaaecd4419e2930927844f3b772668204737a4e7602a2290c991c93c5c4b | Observed malicious Brotli request body |
| User-agent | Mozilla/5.0 (compatible; node2shell-check/1.0) | Separately observed exposure-scanning activity |
These publicly reported indicators are useful for historical correlation but are not comprehensive. The payload hash identifies one specific attempt, and the user-agent can be imitated. Neither establishes successful exploitation on its own.
Security teams should also investigate potential follow-on activity, including unusual access to environment variables, cloud credentials, and sensitive application data after suspected exploitation.
Mitigation and Remediation Recommendations
With active exploitation reported and patches available for multiple affected ecosystems, organizations should prioritize remediation based on both vulnerable component presence and attacker reachability.
1. Identify and Patch Vulnerable Components
The immediate priority is to identify affected Node.js runtimes, Brotli libraries, and third-party applications.
For Node.js, upgrade to versions 22.23.4, 24.22.1, or 26.12.1, or newer patched versions in the applicable release line.
For software using Google Brotli directly, apply the appropriate fixed library release or a vendor-supported backport.
Inventory work should cover production servers, container images, serverless functions, CI/CD systems, development environments, and applications embedding native libraries.
Updating an npm dependency alone does not remediate the vulnerable decoder bundled into Node.js. Similarly, upgrading a system library may not update applications that statically link their own vulnerable Brotli implementation.
Affected images and self-contained binaries should be rebuilt and redeployed, with the patched version verified in the running environment.
2. Restrict Untrusted Brotli Decompression
Where patching cannot be completed immediately, organizations should temporarily prevent untrusted compressed data from reaching vulnerable components.
This may involve blocking incoming HTTP requests with Content-Encoding: br at an ingress proxy, load balancer, or web application firewall when that encoding is not required.
Applications that do not need compressed request bodies can disable decompression through their request-parsing configuration.
However, these mitigations must be evaluated carefully. Blocking inbound Brotli does not protect applications that decompress malicious responses obtained through outbound HTTP requests, nor does it address non-HTTP processing paths.
Disabling response compression alone is also insufficient if the application continues accepting compressed input.
3. Limit the Impact of Successful Exploitation
Applications should run with the minimum privileges required for their intended purpose.
Organizations can reduce potential damage by restricting outbound network connectivity, limiting access to sensitive files and credentials, and applying appropriate container isolation and segmentation controls.
Web application firewalls and intrusion prevention systems should be updated with relevant protections, while recognizing that these controls supplement rather than replace security patches.
4. Hunt for Exploitation Attempts and Validate Remediation
Security operations teams should review relevant HTTP, application, container, and endpoint telemetry from October 21 onward, prioritizing the period after public exploit code became available.
Systems showing evidence of suspicious compressed requests, unexplained Node.js crashes, or unauthorized code execution should receive additional investigation.
Where credible compromise indicators exist, remediation should extend beyond patching to include containment, evidence preservation, persistence checks, and rotation of potentially exposed credentials.
Following deployment, teams should verify the effective runtime and library versions, confirm that previously vulnerable decompression paths now reject malformed input, and continue monitoring newly disclosed vendor dependencies.
Stay Safe. Stay Secure.
OP Innovate Research Team
