Introduction

The National Cyber Coordination and Command Centre (NC4) draws attention to CVE-2026-111497, an out-of-bounds write vulnerability in the Google Brotli decompression library. The vulnerability is also referred to publicly as “Node2Shell” or “HTTP2Shell”. Public proof-of-concept exploits were released shortly after the Node.js disclosure on 21 October 2026, and CISA added the vulnerability to its Known Exploited Vulnerabilities (KEV) Catalog on 27 October 2026 based on evidence of active exploitation. Security researchers have since reported reconnaissance and exploitation activity in the wild.

Successful exploitation may result in memory corruption, disclosure of process memory, denial of service, or remote code execution when an affected application decompresses attacker-controlled Brotli-compressed data. Remote code execution has been publicly demonstrated against official, unmodified Node.js builds.

Exposure depends on whether an affected application or service processes untrusted Brotli-compressed input. The presence of Brotli on a system, or the use of Brotli only for outbound compression, does not by itself establish remote exposure to the vulnerable decoder path.

NC4 recommends that organisations identify systems using affected Brotli decoders, prioritise internet-facing and business-critical workloads where untrusted Brotli data can reach the decompression path, apply vendor-provided security updates, and conduct retrospective review where vulnerable systems were exposed before remediation.

Impact

A specially crafted Brotli-compressed stream can cause the decoder to write beyond an internal memory buffer. Depending on the affected runtime, platform and process context, successful exploitation may result in:

• application or service crashes and denial of service;
• disclosure or corruption of process memory; and
• arbitrary code execution within the security context of the affected process.

Exposure Conditions

Organisations should prioritise systems where attacker-controlled Brotli-compressed data may be decompressed, including:

• applications accepting Brotli-compressed HTTP request bodies (Content-Encoding: br) – for example:
  • Express 5 with express.json() or express.raw(),
  • body-parser 2.x,
  • Koa with @koa/bodyparser,
  • Envoy or Istio with the Brotli decompressor configured,
  • and ASP.NET Core request decompression with the br provider enabled;
• applications or services that automatically decompress Brotli responses from external or untrusted sources – for example:
  • Node.js fetch() (undici),
  • axios,
  • Python requests,
  • httpx or aiohttp where a Brotli package is installed,
  • and .NET HttpClient with Brotli automatic decompression enabled – particularly where an attacker can influence the URL being fetched (such as webhooks, link previews, crawlers or “import from URL” features);
• runtimes or libraries that directly invoke vulnerable Brotli decompression APIs;
• containers, self-contained applications, or statically linked software that bundle an affected Brotli decoder.

Note: Systems that only perform Brotli compression and do not decompress untrusted Brotli input do not expose the vulnerable decoder path through that function. Administrators should nevertheless verify whether the same library is used elsewhere and apply applicable vendor updates.

System Affected

The vulnerability affects multiple ecosystems that incorporate the Brotli decoder. Exact package versions and remediation steps vary by vendor and distribution. Organisations should follow the applicable vendor advisory rather than rely solely on upstream library version numbers, as security fixes may be backported.

Recommendation

NC4 recommends that organisations take the following actions:

A. Identify and Prioritise Exposure

• Identify applications, runtimes, libraries, containers and appliances that use Brotli decompression.
• Determine whether attacker-controlled Brotli-compressed data can reach the vulnerable decoder. Prioritise internet-facing, externally integrated and business-critical systems.
• Confirm the actual deployed runtime or bundled library version rather than relying only on development or host package inventories.

B. Patch, Rebuild and Verify

• Apply vendor-provided security updates as soon as practicable.
• Rebuild and redeploy affected containers, self-contained applications and statically linked software where the vulnerable decoder is bundled with the application.
• Restart affected services where required and verify that the patched runtime or package is the version actually in use.
• For Node.js, verify the installed release with node -v. Do not rely on process.versions.brotli. The fix was applied without changing the bundled version string, so it reports 1.2.0 on both patched and vulnerable builds.

C. Temporary Exposure Reduction

• Where immediate patching is not possible, prevent affected applications from decompressing Brotli data received from untrusted sources where operationally feasible, for example:
  • at the reverse proxy, load balancer or WAF, reject or strip inbound request bodies carrying Content-Encoding: br for services that do not require them (browsers do not send Brotli-compressed request bodies);
  • for ASP.NET Core and .NET HttpClient, remove Brotli only from decompression configuration that is already in use. Do not introduce new decompression settings, as vendor guidance warns this can create other denial-of-service risks.
• Note that outbound requests cannot be reliably protected in this way, because a malicious server may return Brotli-encoded content regardless of what the client requests. Patching is the only remediation for that path.
• Assess the impact of any temporary configuration change on legitimate application functionality.
• Treat temporary controls as risk-reduction measures only. They are not substitutes for applying vendor-provided security updates.

D. Compromise Assessment and Monitoring

• For systems that were vulnerable and exposed before remediation, conduct a retrospective review for signs of exploitation.
• Review application, reverse-proxy and WAF telemetry for unusual Brotli-compressed requests or responses associated with application crashes, memory faults, worker aborts or core dumps.
• Investigate repeated crashes or restarts of Node.js and other Brotli-consuming processes (for example, segmentation faults, Kubernetes CrashLoopBackOff states or process-manager restart bursts). Public exploits are probabilistic, so a successful compromise is typically preceded by multiple failed attempts that crash the worker process.
• Review endpoint and application telemetry for unexpected process execution, unusual child processes (for example, a shell spawned by a node, bun or other runtime process), abnormal outbound connections or other activity occurring shortly after suspected Brotli decoding events. Publicly observed exploit techniques return the shell over the attacker’s existing HTTP connection, so the absence of new outbound connections does not rule out compromise.
• Where core dumps are enabled, treat crash dumps as potentially containing other users’ session cookies, tokens and key material. Restrict access to and retention of core files, and rotate secrets held by affected processes where exploitation is suspected.
• The following publicly reported indicators may support hunting:
  • the reconnaissance User-Agent “Mozilla/5.0 (compatible; node2shell-check/1.0)”;
  • exploit request body SHA-256 7fcbdaaecd4419e2930927844f3b772668204737a4e7602a2290c991c93c5c4b; and
  • Brotli-encoded POST request bodies of approximately 23 MB, or bursts of small Brotli-encoded POST requests.
• Treat these behaviours as hunting opportunities rather than standalone indicators of compromise. Correlate findings with the vulnerable runtime, relevant network activity and subsequent host behaviour.

Reporting

Organisations identifying attempted exploitation or confirmed compromise should report the incident through the appropriate national reporting channel.

NCII entities should continue to comply with applicable reporting obligations under the Cyber Security Act 2024 [Act 854] and associated regulations. Other organisations are encouraged to submit cybersecurity incident reports through NACSA's designated reporting channels.

DISCLAIMER

This advisory reflects information available to NC4 as of 31 October 2026. Exploitation activity, affected product coverage and vendor remediation guidance may change as additional information becomes available. Organisations should continue to monitor official vendor and government cybersecurity advisories for updates.

References

1. CISA - Known Exploited Vulnerabilities Catalog / 27 October 2026 alert    https://www.cisa.gov/known-exploited-vulnerabilities-catalog

2. Node.js - Wednesday, October 21, 2026 Security Releases    https://nodejs.org/en/blog/vulnerability/october-2026-security-releases

3. Canadian Centre for Cyber Security - AL26-027: Critical vulnerability impacting Google Brotli    https://cyber.gc.ca/en/alerts-advisories/al26-027-critical-vulnerability-impacting-google-brotli-cve-2026-111497

4. Red Hat - CVE-2026-111497    https://access.redhat.com/security/cve/cve-2026-111497

5. Microsoft .NET Security Advisory - CVE-2026-111497    https://github.com/dotnet/runtime/security/advisories/GHSA-p3jp-9v83-76w9

6. Google Brotli - Fix commit 0ed4268a (“Detect and report invalid stream earlier”)    https://github.com/google/brotli/commit/0ed4268a