Google Brotli CVE-2026-111497 Explained: Exploitation, Impact and Mitigation
CyberInsights Today · Additional threat analysis
By Harpreet Singh Virdi, CISSP, CCSP
Published and evidence checked on November 5, 2026.
Start with a simple question. Where does your organisation turn Brotli-compressed data back into readable content? That may happen in a public API, a background worker, an outbound HTTP client or a proxy. Each decoding point needs an owner and a patch decision.
CVE-2026-111497 is a memory-corruption vulnerability in Google's Brotli decoder. Google published a fixed release on October 21, 2026. Its release notes describe an out-of-bounds write with potential remote code execution. Google Brotli release notes.
What Brotli does
Brotli compresses content to reduce the amount of data transferred. An encoder makes the compressed representation. A decoder reconstructs the original bytes. In HTTP, Content-Encoding: br identifies Brotli-encoded content. The vulnerable operation here is decoding untrusted compressed data. Finding the word “Brotli” in a dependency list is the start of the exposure assessment. Follow the data to establish whether decoding is reachable.
A useful example is an image-import service. It downloads content from a URL, then an HTTP library automatically decompresses the response. The service is acting as an HTTP client, even though your users think of it as part of your website. Its response-processing path deserves the same scrutiny as the public upload endpoint.
What fails inside the decoder?
A streaming decoder accepts input in chunks and maintains state between them. It must distinguish an incomplete stream, where more bytes may help, from an invalid stream, where processing should stop.
The Node.js security team explains that an invalid block switch was treated as a request for more input instead of a permanent format error. Processing continued and bytes accumulated beyond an internal eight-byte buffer. That can corrupt process memory. The possible outcomes include a crash, disclosure of memory or remote code execution. Node.js technical explanation.
Think of a decoder as a clerk filling a small tray while following instructions. When the instructions become invalid, the clerk should stop. Here, the failure lets the clerk continue filling the tray beyond its boundary. In software, the neighbouring space may hold other state the process depends on.
Illustration 1 · Follow the untrusted bytes
Attacker-controlled request or file → an application accepts it → Brotli decompression.
Application contacts an untrusted server → server returns Brotli data → client library decompresses it.
Possible service crash, memory disclosure or code execution. Actual consequences depend on the process and exploit conditions.
How can it be exploited?
The starting point is control over compressed input. The next requirement is a path that sends that input to an affected decoder. An application may expose such a path through explicit decompression code or through a library that performs it automatically.
For an inbound path, an application accepts a compressed request body or uploaded content and decompresses it. Whether an unauthenticated person can reach that operation depends on where authentication, parsing and decompression occur.
For an outbound path, a service fetches data from a source an attacker controls or can influence. The response is decoded inside the service. Bun's advisory gives a concrete example of automatic Brotli response decompression in its HTTP client. Microsoft also identifies automatic response decompression and explicit decoder APIs as exposure paths when enabled. Bun exposure analysis, Microsoft application prerequisites.
Analysis. Map who can supply bytes, where decoding happens and what permissions the process holds. Exploitability varies with the build, memory layout and runtime protections. A crash demonstrates an availability failure. Successful control of execution requires additional conditions beyond merely causing that crash. The cited sources establish a serious code-execution risk without proving identical exploit reliability in every application.
Criticality and evidence of exploitation
Envoy and Brotli4j publish a CVSS v4.0 score of 9.2, Critical, with network access, no required privileges or user interaction, and attack requirements present. Microsoft rates its product scenario CVSS v3.1 8.1, High. Keep the scoring version and product context attached to the number. Envoy severity assessment, Brotli4j assessment, Microsoft scoring.
The Canadian Centre for Cyber Security's October 28 alert states that CISA added this CVE to its Known Exploited Vulnerabilities catalogue on October 27. This is evidence supporting urgent remediation. The alert does not identify a specific victim or establish an exploitation timeline for every affected product. Cyber Centre alert AL26-027.
Operational assessment. Prioritise reachable decoders processing untrusted input, especially in public services, shared proxies and privileged workers. An internal job that downloads external content can also deserve emergency treatment. Document the reachable path and business impact alongside the score.
Potential impact on the business
- Availability. Decoder crashes can interrupt requests or background processing. Repeated failures may exhaust worker capacity and delay dependent operations.
- Confidentiality. A memory disclosure may expose data present in the affected process. The actual data at risk depends on what that process handles.
- Integrity. If code execution succeeds, an attacker may act with the process's permissions. Accessible files, credentials and downstream services determine the potential reach.
These are risk scenarios to assess against your environment. Use process identity, network reach, secret access and tenant boundaries to estimate the consequences rather than assuming every affected deployment has the same blast radius.
Affected components and fixed code
The upstream fixes are branch-specific. The Cyber Centre lists these ranges and fixes. Official affected-version table.
| Affected upstream range | Fixed branch release |
|---|---|
| 1.0.3 through 1.0.9 | 1.0.10 |
| 1.1.0 | 1.1.1 |
| 1.2.0 | 1.2.1 |
Use this table to recognise the underlying component. The patch you deploy may be a runtime update, distribution package, application rebuild or firmware release containing the corrected decoder. Match the supplier's security notice to the artifact actually deployed.
A bundled copy requires particular care. Brotli4j documents that its native library is shipped inside application artifacts, so updating the operating system library leaves that bundled copy in place. Bun likewise requires rebuilding compiled executables containing an affected runtime. These examples explain why dependency ownership matters across technology stacks. Bundled native library evidence, Embedded runtime evidence.
Mitigation across your environment
- Find every decoding point. Inventory applications, runtimes, containers, gateways, third-party products and background jobs. Search dependency records and application configuration, then ask the owner where untrusted compressed data enters.
- Apply the fix through the owning product. Upgrade to a supported artifact containing the corrected decoder. Rebuild statically linked or bundled applications where required. Replace running instances and complete any required restart.
- Block the vulnerable operation while patching. Prevent untrusted Brotli content from reaching affected decoding paths. Cover inbound bodies, downloaded responses and direct file-processing APIs. The Cyber Centre recommends this approach when immediate updating is not feasible. Temporary mitigation guidance.
- Validate the control before relying on it. Test that the application rejects unsupported content cleanly and that another component does not decode it first. Review compressed-data handling at each hop. Changing advertised encoding preferences alone needs verification against actual response handling.
- Limit consequences. Run decoding processes with the permissions they need. Restrict secret access and outbound destinations, and isolate resource consumption. These controls reduce potential impact while remediation proceeds.
Illustration 2 · From inventory to verified remediation
- Locate the decoder and its owner.
- Trace incoming requests, downloaded responses and file inputs.
- Contain untrusted decoding while deploying the fix.
- Replace affected runtimes, bundled artifacts and running instances.
- Verify the active build, data paths and normal service behaviour.
Where a WAF or reverse proxy can help
Defensive analysis. An ingress control can reject Brotli-encoded requests on a path it governs, where that behaviour is supported and verified. First establish whether the control itself performs decompression and needs a security update. Envoy's advisory specifically identifies deployments with the Brotli decompressor configured as affected. Proxy decoder exposure.
For an application fetching content from an external server, inspect the outbound response-processing path separately. Draw both directions. Confirm where TLS ends, which component sees the body and which decoder processes it. Keep a vendor-supported signature scoped to its documented coverage and complete the underlying code update.
Detection and investigation
Look for unexpected process exits, native memory errors, decoder failures and unusual worker restart patterns. Correlate those events with requests, downloads and background jobs at the same time. Record the source and destination, content encoding, service identity and affected instance where your telemetry permits.
Then review process creation, outbound connections, file changes and access to secrets around suspicious failures. These are investigation leads, not CVE-specific proof. Preserve relevant logs and crash artifacts under your incident-response process because they may contain sensitive process data. Escalate evidence of compromise for investigation even after the patch rollout succeeds.
How to verify the fix
Record the owning product's advisory and fixed artifact, the installed revision, running image digest or application build, deployment time and restart evidence. Account for every active backend, standby and image that can be redeployed. Check a bundled decoder through the application build record as well as the host package inventory.
Test ordinary workflows and verify that temporary encoding restrictions behave as intended. Use authorised, non-destructive assessment methods appropriate to the service. Keep the evidence in the change ticket. Our earlier bulletin explains this process using a backend example. Patch verification in production.
What to take away
Trace the bytes to the decoder, identify the artifact that owns it, and get fixed code running in every reachable instance. Include outbound clients and embedded copies in the search. Where patching takes time, stop untrusted Brotli decoding on the affected paths and verify that the containment works.
References and evidence
- Google Brotli 1.2.1 release, October 21 — upstream security fix.
- Node.js October 21 security release — decoder failure mechanism.
- Canadian Cyber Centre AL26-027, October 28 — impact, fixed upstream branches, KEV statement and interim mitigation.
- Bun advisory, October 23 — automatic response decoding and embedded runtimes.
- Microsoft advisory, October 25 — application prerequisites and CVSS v3.1 scoring.
- Envoy advisory, October 23 — decompressor exposure and CVSS v4.0 assessment.
- Brotli4j advisory, October 24 — bundled native code and severity.
Independent educational analysis. No exploit or product configuration was tested for this article. Source details were checked on November 5, 2026. See our editorial disclosure.
Comments
Post a Comment