Executive summary

CVE-2026-111497 affects Google's Brotli decoder and reaches applications through dependencies in several language runtimes, according to the Canadian Centre for Cyber Security. The US Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities catalogue on 27 October 2026. Exposure requires a vulnerable decoder to process untrusted compressed data, and vendor guidance differs between products and deployment models. We assess that checking both bundled library versions and decompression paths is likely (B2) to uncover gaps that a Node.js-only patch campaign would miss, because primary advisories identify affected Python, .NET and PHP dependencies as well.

The component and the exposure condition

The Canadian Cyber Centre's 28 October alert describes an out-of-bounds write in the decoder. It identifies possible outcomes including memory disclosure, crashes and arbitrary code execution. These are potential consequences of successful exploitation, not a claim that every application using Brotli has suffered all of them.

CISA's entry confirms exploitation of the vulnerability but does not identify which of the downstream products listed here was involved. A product's inclusion in an affected-dependency inventory should therefore remain distinct from campaign attribution or evidence of compromise.

The upstream releases provide fixes across three branches. The Canadian alert gives the following affected ranges and corresponding updates:

Brotli branch Affected versions Fixed release
1.0 1.0.3 through versions before 1.0.10 1.0.10
1.1 1.1.0 through versions before 1.1.1 1.1.1
1.2 1.2.0 through versions before 1.2.1 1.2.1

The 1.0.10, 1.1.1 and 1.2.1 release notes all identify the security fix. Use the affected product vendor's package guidance where Brotli is bundled or backported, rather than assuming an operating-system library update replaces every copy.

Node.js: update the runtime serving the workload

The Node.js October advisory includes CVE-2026-111497 among its high-severity fixes. It identifies applications that decompress attacker-controlled Brotli data through node:zlib as exposed and lists updates for Node.js 22, 24 and 26: 22.23.4, 24.22.1 and 26.12.1 respectively.

Our recommended audit should include deployed service images and application-bundled runtimes, not only the Node.js executable on an administrator's shell path. Record which runtime the serving process actually loads, replace the deployment with the corrected build and validate normal compressed-content handling using benign data.

This dependency issue is only part of the October Node.js release. Our separate Node.js article covers the rest of that release; the primary vendor advisory remains the authority for affected branches and fixes.

Python: inspect the native package as well as application code

The Python Packaging Authority's (PyPA) PYSEC-2026-4322 record states that the PyPI Brotli package includes the same vulnerable C decoder. It lists releases through 1.2.0 as affected and 1.2.1 as fixed. Updating JavaScript services does not update this Python dependency.

The record also identifies automatic response decompression in common HTTP clients when Brotli support is installed, alongside services that accept Brotli-encoded request bodies. That makes both inbound and outbound data flows relevant. An outbound HTTP client can receive untrusted compressed data even when the application does not expose a public upload endpoint.

As an operational recommendation, inspect the installed package in each production environment, the dependency lockfile used to build it and the resulting deployment artifact. Check optional HTTP-client extras and any direct calls to decompression functions. Rebuild and redeploy where the fixed package is incorporated into an image; avoid closing the ticket merely because a development environment resolved a newer dependency.

The Python record concerns the named Brotli package. The Canadian alert additionally lists brotlicffi; do not substitute the former package's version number for the latter's vendor-specific remediation instructions.

.NET: configuration and publishing model matter

Microsoft's .NET advisory explicitly says that ASP.NET Core and HttpClient do not automatically decompress Brotli content in their default configurations. Exposure arises when an application enables the relevant decompression support or directly passes untrusted data to Brotli decompression interfaces. The .NET Framework is not affected by this advisory.

Microsoft lists these corrected runtime versions:

Product line Corrected runtime
.NET 8 8.0.33
.NET 9 9.0.22
.NET 10 10.0.14
.NET 11 previews 11.0.0-rc.3.26522.148

The advisory also supplies corresponding software development kit (SDK) versions and package-specific ranges. Use those tables when build tooling or explicit package references determine what gets shipped.

The deployment distinction is consequential. Microsoft instructs users to restart applications after the update; self-contained applications require rebuilding and redeployment. NativeAOT applications require a patched SDK and any explicit compiler or runtime-pack references, followed by republishing and redeployment. Updating a machine's shared runtime alone does not replace a decoder already linked into a NativeAOT executable.

For temporary mitigation, Microsoft recommends avoiding decompression of attacker-controlled Brotli data. It warns against adding decompression configuration to an application that did not already use it merely to copy a mitigation example. Review existing settings, change only the affected path and test the consequences for normal traffic.

PHP Windows: a rebuilt package with the same PHP version

PHP's 26 October notice announces rebuilt Windows packages containing Brotli 1.2.1. The package names are 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1; the PHP source and runtime version numbers themselves are unchanged. For these packages, checking only a short PHP version string cannot distinguish the original bundle from the replacement.

The notice identifies the bundled cURL dependency as the relevant path. Automatic HTTP response decompression is disabled by default but applications or libraries can enable it. The recommended audit is therefore to record the Windows distribution package identity and inspect how the application uses response decompression.

Keep this ticket distinct from the two PHP request-lifecycle vulnerabilities fixed on 21 October. PHP's rebuilt Windows package addresses an additional dependency concern; the existence of the earlier runtime fix does not establish that the Brotli dependency has also been replaced.

A practical verification record

For each affected workload, our recommended record contains five items:

  1. Component: the runtime or library package actually deployed, including its distribution provenance.
  2. Reachability: whether untrusted Brotli data can reach the decoder through inbound requests, outbound responses or direct library calls.
  3. Correction: the vendor's fixed version or backport and the artifact that contains it.
  4. Activation: evidence of restart, image replacement or application republishing, as appropriate to the deployment.
  5. Validation: a benign functional check and confirmation that the maintained deployment definition retains the corrected dependency.

The Canadian alert recommends identifying internet-facing uses and third-party dependencies, applying updates, and temporarily preventing untrusted Brotli processing where an update cannot yet be applied. It also advises monitoring unexpected crashes and abnormal process behaviour. Those observations should trigger investigation; they are not unique signatures of this vulnerability.

Assessment and limits

We assess that dependency ownership is likely (B2) to be the main coordination challenge for remediation across mixed runtime estates. This judgement follows the distinct packaging and deployment instructions in the Node.js, Python, Microsoft and PHP sources, rather than a measured claim about patch rates in organisations.

The evidence supports a broad component inventory and prioritised remediation. It does not support assigning every crash to exploitation, asserting that every application with the library is reachable, or claiming that exploitation has been observed in each downstream product. Keep those limits visible when reporting progress to service owners.

Further reading