What happened
On 21 October 2026, Google published Brotli 1.2.1 and described CVE-2026-111497 as an out-of-bounds write that permits remote code execution. On 21 October 2026, the Node.js project published fixes for supported 22.x, 24.x and 26.x lines and said malformed Brotli input could corrupt process memory. On 27 October 2026, CISA added CVE-2026-111497 to the Known Exploited Vulnerabilities catalogue, according to SecurityWeek. That final step materially changed the enterprise decision: the issue is no longer supported only by severity and laboratory analysis, but by an authoritative determination that exploitation is occurring.
Palo Alto Networks identifies Google Brotli versions 1.0.3 through 1.2.0 as affected by crafted Brotli-compressed streams that can corrupt memory, disclose data, crash a process or potentially execute code. Node.js says affected applications are those that decompress attacker-controlled Brotli data through node:zlib, with possible crash, memory disclosure or remote code execution. The shared component can be compiled directly into products, which means a package manager, operating-system scanner or central software inventory may not identify every affected copy.
For PAN-OS 11.2.4 or later, the command show system setting brotli identifies exposure: Enabled: yes means Brotli inspection is active. Palo Alto Networks says PAN-OS exposure requires Brotli inspection and TLS/SSL decryption on the dataplane; the management interface is not affected. The cited sources did not publish a stable malicious payload hash, source-IP set or domain list suitable for blocking. Attribution posture: CISA’s exploitation confirmation named no actor, and no campaign attribution had been established in the cited sources.
Why this matters now
The material change is exploitation status. SecurityWeek reported CISA’s addition of CVE-2026-111497 to the Known Exploited Vulnerabilities catalogue, while the vulnerability sits below recognisable products and frameworks. A conventional product-name scan can therefore miss the copies embedded in application containers, language runtimes, native extensions, self-contained binaries and network appliances.
Reachability matters more than package presence. Exposure requires an affected decoder to process attacker-controlled Brotli data, but that path may exist in web responses, uploaded files, service-to-service requests or inspection engines. Security leaders need an application and traffic-path decision, not a raw software-bill-of-materials count that treats every installed copy as equally dangerous.
The PAN-OS case demonstrates the operational trade-off. Brotli inspection combined with TLS/SSL decryption creates exposure in the dataplane, while disabling decompression reduces risk but changes inspection coverage. Similar trade-offs will exist wherever security controls, gateways or proxies decompress untrusted content before applications receive it.
The decision for security leaders
Direct the CTO and application-security function to produce a reachability-ranked inventory, separating exposed decompression paths from dormant library presence. Require product owners to state the input source, decoder implementation, deployment model, fixed version and remediation date for each reachable path.
Run patching and incident response as parallel workstreams. Updating a component prevents subsequent exploitation but does not establish that an internet-facing process was not previously reached. Systems with exploitable paths need log review, crash analysis, integrity validation and credential-impact assessment before closure.
Treat inspection workarounds as explicit security exceptions. Disabling Brotli decompression may reduce exploitability while also reducing visibility into compressed traffic; the accountable owner should document compensating controls, service impact, review date and the condition for restoring normal inspection.
Evidence of closure
- A signed inventory identifies every reachable Brotli decoder and its accountable owner.
- Production evidence shows affected runtimes or embedded components were replaced with fixed builds.
- PAN-OS configuration exports show patched status or an approved Brotli-inspection exception.
- Incident records document compromise findings for every previously exposed decompression path.
The Security.io assessment
This is a dependency-governance event with exploitation evidence, not a reason to declare every Brotli installation compromised. The decisive question is whether an affected decoder processed attacker-controlled content. Organisations that cannot answer that question quickly have an inventory and architecture problem extending beyond this CVE.
Vendor statements must be read at the correct layer. CISA’s KEV decision applies to the vulnerability, while individual suppliers may have different configurations, embedded versions, mitigations or evidence about attacks against their products. Product-specific affectedness remains essential even though the vulnerability-level exploitation status is confirmed.
Absence of block-ready indicators increases the value of behavioural evidence: unexplained process crashes, memory-safety faults, service restarts and abnormal behaviour in decompression paths. Those signals are not proof of exploitation, but they should move an exposed asset from routine patching into incident triage.
Questions for the morning meeting
- Can engineering identify every internet-reachable path that decompresses untrusted Brotli content?
- Which products contain statically linked or vendored Brotli copies that operating-system patching will not replace?
- Which exposed systems require compromise assessment rather than patch-only closure?
- Can vulnerable decompression be disabled without breaking customer traffic or security inspection?
- Who can approve temporary exposure exceptions, and when do those exceptions expire?