Åland · Finland · SwedenIndependent sources. Practical action.
ÅlandSecurity BlogIT security in practice
← All articles
CVSS 9.2● Known exploitation

Brotli 9.2: the flaw may be in a dependency

Brotli is embedded in other programs. Check that the vulnerable component is also updated when the main program is patched.

Published 31 Oct 2026 · Updated 31 Oct 2026 · 2 min read
Sources checked 31 Oct 2026 · Source date 2026-10-28 · AI-assisted content
Recommended next step

Identify affected programs and install the vendor's corrected packages.

What is confirmed

CVE-2026-111497 concerns a memory-handling flaw in the Brotli decoder. CERT-SE reports a score of 9.2 and inclusion in CISA KEV. Google has released Brotli 1.2.1 with a fix. [1, 2]

Versions to check

CERT-SE lists Brotli 1.0.3–1.2.0. For Python packages, the advisory lists fixes in brotli 1.2.1 and brotlicffi 1.2.1.0. Also assess whether the program decodes data an attacker can influence. [1, 3]

Our practical checks

Check the program that actually runs, including its embedded libraries.

  1. Identify products and your own applications that use Brotli decoding.
  2. Ask the vendor to confirm the status of your product version. An updated system library does not necessarily fix embedded copies.
  3. Use the product's supported update method. For your own code, update the dependency, rebuild and deploy.
  4. Check the running version and test the service's most important functions.

For private users

Install program and system updates using trusted update mechanisms. Avoid standalone “security fixes” from unknown websites. For a web service you run yourself, you or the hosting provider need to check the platform.

Take the fix all the way to production

This is our dependency-update workflow. The target version and any additional requirements must come from the advisory for your product.

  1. For a packaged product, obtain the vendor's package that explicitly fixes the affected Brotli component.
  2. For your own application, update the correct dependency and lockfile, build a new release or container image and deploy it to every affected instance.
  3. Check the component in the running deployment. A new file in the build environment is not enough while old instances are still running.
  4. Test normal operation and review errors after rollout. Do not use a public exploit as a functional test.

Need a common workflow?

The guide “A vulnerability has been found – take it through to a verified fix” explains how to check whether you are affected, prepare recovery and verify the result.

Sources

  1. CERT-SE: Critical vulnerability in Google Brotli ↗
  2. Google Brotli: release 1.2.1 ↗
  3. GitHub Advisory Database: CVE-2026-111497, CVSS 4.0 ↗

Numbers in the text refer to the sources above. Workflows and checklists are the blog's practical recommendations.