Downloading a webpage, calling an API, or importing remote content feels routine. Sometimes, however, the dangerous part is not the visible content. It is something that happens before the application can read that content: decompressing the response.

CVE-2026-111497 is an out-of-bounds write vulnerability (CWE-787) in the Brotli decoder, part of a compression format widely used on the web. A specially malformed compressed stream can corrupt memory when a program attempts to decode it.

The issue is not exclusive to a particular website or video extractor. It may affect browsers, HTTP clients, backend services, language runtimes, and libraries that incorporate an affected decoder and process attacker-controlled Brotli input.

What Brotli is and why so many applications use it

Brotli is a lossless compression algorithm. In HTTP, it is typically negotiated with the br encoding.

GET /resource HTTP/1.1
Host: example.org
Accept-Encoding: gzip, deflate, br

A server might reply:

HTTP/1.1 200 OK
Content-Encoding: br
Content-Type: application/json

Before the client can parse the JSON or HTML, it must decompress the bytes. That step often runs within a native library or a runtime, so applications may rely on Brotli without importing it directly.

Having the package installed does not, by itself, prove exploitability. Exposure depends on the decoder version and whether an untrusted stream can reach it.

What goes wrong in CVE-2026-111497

According to the Node.js security advisory, an invalid block-type switch in the Brotli decoder was reported as a temporary need for additional input instead of a permanent format error.

In the streaming decompressor, this allowed more bytes to be appended to an internal eight-byte buffer past its boundary. That behavior can corrupt the memory of the hosting process.

Untrusted Brotli-compressed input
               |
               v
       Vulnerable decoder
               |
        Malformed block
               |
               v
  Format error mistaken for "need more input"
               |
               v
   Write beyond internal buffer
               |
        Memory corruption

Possible outcomes include process crashes, exposure of process memory, and, under some conditions, code execution. These are distinct possibilities, not guaranteed consequences: the impact depends on the application, attacker control, and runtime mitigations.

The October 26 Red Hat bulletin describes public demonstrations of crashes and memory corruption but notes that no reliable public remote-code-execution exploit has been observed. It is essential to distinguish potential impact from publicly demonstrated exploitation.

Which versions are affected?

The official CVE record identifies the following Google Brotli branches:

BranchAffected versionsFirst fixed release in that branch
1.0.x1.0.3 through 1.0.91.0.10
1.1.x1.1.01.1.1
1.2.x1.2.01.2.1

The Brotli project released fixes. For projects following the 1.2 branch, 1.2.1 or later contains the security fix. Linux vendors may backport the patch while keeping a different upstream version number, so consult their security advisories.

For Node.js, the fixed releases listed in the October 21 advisory are 22.23.4, 24.22.1, and 26.12.1. The appropriate remedy is a supported, patched Node.js runtime—not just upgrading an unrelated Python package.

Products that embed their own decoder, including browsers, proxies, containers, and compiled applications, require their own security updates.

When is an application actually exposed?

One plausible scenario is an HTTP client downloading Brotli-compressed responses from an attacker-controlled source—for example, a URL supplied to a content importer or an API accepting compressed data. Decompression may happen automatically before application-level validation.

Other applications explicitly invoke decompression, such as Node.js code calling zlib.brotliDecompress().

Three shortcuts lead to misleading conclusions:

  • “My app downloads videos, therefore it is vulnerable.” Not necessarily. The decoder, runtime, configuration, and control over the response all matter.
  • “Brotli is installed, therefore anyone can access my server.” Installation alone does not establish a reachable attack path.
  • “Remote code execution is possible, therefore exploitation has occurred.” A potential outcome is not evidence of a compromise.

The useful question is: Does any process decompress third-party-controlled Brotli data with an unpatched decoder?

A quick Linux, Python, and Node.js audit

These commands collect diagnostic information. They do not change running services and are not a comprehensive vulnerability scan.

# Debian/Ubuntu packages
dpkg-query -W '*brotli*' 2>/dev/null
apt-cache policy libbrotli1 python3-brotli

# The Python environment used for this command
python3 -m pip show Brotli brotlicffi

# Node.js runtime
node --version
node -p "process.versions.brotli"

# Shared libraries known to the linker
ldconfig -p | grep -i brotli

Read the results carefully:

  • pip show inspects only the selected Python environment; inspect the virtual environments actually used by each service.
  • process.versions.brotli identifies a bundled component but cannot alone prove whether a vendor backported a particular security fix.
  • dpkg-query cannot inventory Python wheels, statically linked binaries, or the libraries inside container images.
  • Docker images need patched bases and dependencies, followed by a rebuild and redeployment.

For meaningful coverage, combine package inventories, SBOMs, vendor advisories, and functional tests for real download paths.

Remediation, in priority order

  1. Map entry points. Identify endpoints, HTTP clients, importers, and background jobs that decode externally supplied br responses.
  2. Patch each affected copy. Apply vendor fixes for system packages, update Python dependencies, and use a patched Node.js runtime. Rebuild binaries and container images that embed vulnerable code.
  3. Test before release. Check legitimate downloads, media types, compressed responses, and resource limits. Restart processes that still have old libraries loaded.
  4. Mitigate if patching is delayed. Where supported, temporarily disable Brotli decoding or reject responses with Content-Encoding: br before decompression. Removing br from Accept-Encoding alone does not prevent an untrusted server from sending it. Verify the functional impact.
  5. Verify the result. Confirm the versions actually loaded at runtime and that vulnerable decoding paths are no longer reachable.

Companion guide: when a patched package is not yet available or dependencies must be preserved, see how to reduce Linux attack surface by blocking fwupd and PackageKit while keeping APT and unattended-upgrades enabled. This is a temporary mitigation, not a replacement for patching.

A broad, untested upgrade is not automatically safer than a targeted, verified fix—especially in production environments.

The larger lesson: decompression is a trust boundary

Decompression processes untrusted bytes, transforms them, and often runs below the application code that eventually validates the resulting document.

CVE-2026-111497 demonstrates that application security is not only about sanitizing URLs, HTML, or JSON. It also depends on the code that interprets compressed input, the runtime shipping that code, and embedded copies that a superficial package upgrade may miss.

The proportional response is straightforward: inventory, verify exposure, patch, test, and confirm. Avoid both dismissing memory-corruption vulnerabilities and treating every installation as already compromised.

References and further reading