PolicyCortex
Request Access
Summary
  • CISA added the Brotli decoder flaw to its exploited list on October 27, 2026.
  • The flaw affects Brotli versions 1.0.3 through 1.2.0 on all platforms.
  • Fixed versions are 1.0.10, 1.1.1, and 1.2.1, by release line.
  • A library flaw hides inside many products, so the version check must cover each one.

What changed on October 27

The Cybersecurity and Infrastructure Security Agency (CISA) added a new flaw to its list. The list is the Known Exploited Vulnerabilities (KEV) catalog. CISA lists a flaw there only when exploitation is known. The new entry is CVE-2026-111497. Common Vulnerabilities and Exposures (CVE) is the record system for public flaws. Federal civilian agencies must act by November 10, 2026. The order comes from Binding Operational Directive 26-04. That directive sets how federal agencies rank security updates by risk.

How the flaw works

Brotli is a compression format for web data. A decoder reads compressed data and turns it back into plain data. The flaw sits in the decoder code, in file c/dec/decode.c. A remote attacker needs no account and no login. The attacker sends a crafted Brotli compressed stream. The decoder fails to check a return value. That failure corrupts nearby decoder memory. It can leak memory contents or crash the service. It can also run attacker code in some cases. The flaw affects Brotli versions 1.0.3 through 1.2.0. It affects all platforms, not just one operating system.

Why a library flaw is hard to find

Brotli is a library, not a product you install on its own. Many runtimes, servers, and tools bundle it inside their own code. A team may patch one visible install and miss five bundled copies. Each bundled copy still runs the old decoder code. Each one still accepts crafted streams from remote senders. A version check must list every product that bundles Brotli. It must list the Brotli version inside each product. Vendors ship their own updates for bundled copies. Your patch is done only when each bundled copy is fixed.

What to prove after patch day

Fixed versions depend on your release line. Line 1.0 needs 1.0.10 or later in that line. Line 1.1 needs 1.1.1 or later in that line. Line 1.2 needs 1.2.1 or later in that line. Record the old version and the new version for each product. Record the date each product was patched. Record the scan result after the patch. Keep that record with the flaw entry in your tracker. An assessor will ask for the version before and after. An assessor will ask for the date and the scan proof. A list of patched products with no versions is not proof.

The governance lesson

A catalog listing changes the priority of a flaw. Before the listing, teams could rank this flaw by score alone. Scores for this flaw differ across sources, so score alone gave no clear order. After the listing, the order is clear. Exploitation is known, so the flaw moves to the front of the queue. That is how a KEV listing should work in your own process. When CISA lists a flaw, your tracker should move it up at once. Waiting for a perfect score or a second report wastes the warning. The proof habit matters as much as the patch. Patch fast, then keep the version record that proves it.

Sources

Next step

Check every product you run for a bundled Brotli decoder. Patch each one to its fixed line. Keep the version record that proves it.

Questions on this record
What is Brotli?
Brotli is a compression format for web data. Software uses it to shrink data before sending it. Many tools bundle the Brotli decoder library.
Which versions are fixed?
Line 1.0 is fixed at 1.0.10. Line 1.1 is fixed at 1.1.1. Line 1.2 is fixed at 1.2.1. Update to the fix that matches your release line.
What is the federal deadline?
Federal civilian agencies must act by November 10, 2026. That date comes from the CISA listing. Other teams should treat it as their deadline too.
Is exploitation confirmed?
Yes. CISA lists a flaw in this catalog only when exploitation is known. The listing itself is the confirmation.

Related records

Guides and articles describe the work. The evidence that work produces is described in three proof pages and one architecture page.

proof.state
Proof of State. What the environment was, as of a date someone else picks: point-in-time records, content hashed and chained.
proof.change
Proof of Change. Who or what altered the environment, under what authority, with before and after state hashes.
proof.agency
Proof of Agency. What a machine was permitted to do before it acted, what it did, and what would have stopped it.
architecture
Architecture. How the chain is built and where it lives: inside your tenant, with no egress of evidence.

Further reading in this register

  1. Two Wasmtime Flaws Break the Sandbox PromiseTwo flaws score 9.9. Each lets a crafted module escape its sandbox. The fix is a version check, not a new tool.5 min
  2. Three NGINX Memory Flaws Score 9.2: Check Your Config and PatchF5 published an out-of-band notice on October 14, 2026. It fixes three NGINX memory flaws. Each scores 9.2 under the newest scoring version.5 min
  3. Eight Listed 10.0 Flaws in HPE ArubaOS: Patch Your Wireless Controllers NowHPE published advisory HPESBNW05162 on October 22, 2026. It fixes 72 flaws in ArubaOS 8 and 10. HPE rates eight at 10.0, and one of those IDs needs a closer look.5 min

Verify the record this entry describes.

Request AccessBook a call
Published
Last updated
Unchanged since publication
Author
Leonard Esere