As reported by BleepingComputer on October 28, 2026, CISA has confirmed active in-the-wild exploitation of CVE-2026-111497 — a critical out-of-bounds write vulnerability in the Google Brotli decoder, tracked under the names Node2Shell, Broccoli2Shell, and HTTP2Shell. The agency added the flaw to its Known Exploited Vulnerabilities Catalog and set a November 10 remediation deadline for federal agencies under BOD 26-04. But the exposure extends far beyond the federal enterprise.

Security Impact: As reported by BleepingComputer on October 28, 2026, CISA has confirmed active in-the-wild exploitation of CVE-2026-111497 — a critical out-of-bounds write vulnerability in the Google Brotli decoder, tracked under the names Node2Shell, Broccoli2Shell, and HTTP2Shell.

Vulnerability Details

CVE Identifier
CVE-2026-111497
Severity
Critical
Root Cause
Out-of-bounds write / unchecked return value in the Brotli decoder
Affected Components
Google Brotli compression library; Node.js runtime; .NET framework (per Microsoft emergency patch); any HTTP server or client using vulnerable Brotli implementations
Attack Requirements
Unauthenticated remote attacker; requires only the ability to send a crafted Brotli-compressed stream
Impact
Memory corruption, denial of service, sensitive memory disclosure, potential remote code execution
Patch Status
Patches available — Microsoft has issued an emergency .NET update; Node.js and Brotli library updates available
Active Exploitation
Confirmed by CISA; added to KEV catalog October 28, 2026

Why This Matters More Than It Appears

Brotli is not a niche library. It is the default content-encoding mechanism for an enormous portion of modern web traffic — embedded in every major browser, supported by CDNs, reverse proxies, API gateways, and application runtimes across the stack. A vulnerability in the decoder doesn't just affect one product; it creates a systemic exposure point wherever compressed HTTP payloads are processed.

The attack primitive is particularly dangerous: an unauthenticated attacker needs only to deliver a crafted Brotli-compressed stream to a vulnerable decoder. There is no authentication requirement, no complex interaction chain. Any service that accepts Brotli-encoded request bodies or processes Brotli-compressed responses from upstream systems is a viable target. This includes REST APIs accepting Content-Encoding: br, server-side fetch operations decompressing upstream responses, and intermediary proxies performing content transformation.

The fundamental challenge here is that compression libraries are trusted infrastructure — they sit below the application layer, rarely audited, and almost never on the security team's radar. This is the same class of systemic risk we saw with Log4j andxz-utils: a ubiquitous foundational component with a critical exploitable flaw.

Cross-Platform Ripple Effects

Microsoft's emergency .NET patch signals that this is not isolated to Node.js. Any runtime, framework, or intermediary that links against a vulnerable Brotli implementation is affected. That includes containerized microservices, serverless platforms that process compressed payloads, and potentially mobile applications performing client-side decompression. Security teams who focus only on Node.js patching will miss exposure points in their .NET services, Go binaries statically linking Brotli, or managed cloud services performing transparent decompression.

Who Is Most Exposed

Who Is Most Exposed
API-heavy environments — services accepting Brotli-compressed request bodies expose the decoder to unauthenticated input directly
Node.js and .NET application stacks — explicitly called out by CISA and Microsoft; both received emergency patches
Containerized deployments — statically linked Brotli libraries in container images require full rebuilds, not just runtime patches
Reverse proxy and CDN configurations — intermediaries that perform content decompression may pass crafted streams through to vulnerable decoders
Server-side fetch / SSRF-adjacent patterns — applications that decompress upstream HTTP responses can be triggered via attacker-controlled upstream content

Shield53 Recommendations

Immediate Actions

  1. Patch all Brotli-dependent systems — update the Google Brotli library, Node.js runtime, and .NET framework to their latest patched versions. Do not assume a single-layer patch is sufficient.
  2. Apply Microsoft's emergency .NET update — if running .NET services, this is not optional. Review Microsoft's security bulletin for affected versions and apply immediately.
  3. Rebuild and redeploy all container images — runtime patches do not remediate statically linked libraries inside containers. Rebuild from updated base images and redeploy.
  4. If patching is delayed: block or strip Content-Encoding: br at the WAF, reverse proxy, or load balancer layer. Disable Brotli decoding on inbound request processing. Accept the performance tradeoff — degraded compression is preferable to remote code execution.
  5. Restart all affected processes after patching — in-memory vulnerable library instances persist until process restart.
  6. Hunt for compromise — since exploitation is confirmed active, review logs for unexpected crashes in Brotli-processing services, anomalous memory behavior, and post-exploitation indicators on exposed hosts. Any service that was internet-facing and accepting compressed payloads prior to patching should be treated as potentially compromised.

Broader Hardening

Organizations should inventory all dependencies on compression libraries — not just Brotli, but zlib, zstd, and similar — as part of their SBOM. Compression codecs are a recurring source of memory corruption vulnerabilities. Treat them as the high-value attack surface they are: fuzz-test decoders in your CI pipeline, restrict content-encoding acceptance on public-facing APIs to only what is necessary, and ensure your WAF can inspect and reject malformed compressed streams before they reach application code.

The November 10 KEV deadline applies to federal agencies, but every organization with internet-facing services should treat this as a 72-hour patching window, not a two-week one. Active exploitation means the window between vulnerability and compromise is already closing.