HTTP2Shell Reaches Python: Check the Brotli Decoder, Not Just Your Web Server

A Python service can use a Brotli decoder without an explicit Brotli import in its own source. That makes the response to CVE-2026-111497 a dependency and deployment check, rather than simply a search through application code. As of October 24, 2026, the reviewed advisory lists fixes for both Python packages, Brotli and brotlicffi. The nickname “HTTP2Shell” does not establish a flaw in HTTP/2 or TLS itself. [Current advisory](https://github.com/advisories/GHSA-9v8h-qqgm-4m35)

Follow the decoder, not the nickname

Node.js’s October 21 security notice describes malformed Brotli input writing beyond an internal decoder buffer. If an application decompresses attacker-supplied data with the affected Node decoder, possible outcomes include crashes, process-memory disclosure or remote code execution. That is context for the shared component; it is not proof that every Python application has the same reachable attack path. [Node.js notice](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases)

urllib3’s own documentation says Brotli support becomes available when Brotli or brotlicffi is installed; its optional brotli extra can install that support. A direct application import is therefore the wrong boundary for an inventory. Check what the HTTP client can actually decode in the environment that runs the service. [urllib3 documentation](https://urllib3.readthedocs.io/en/stable/advanced-usage.html#brotli-encoding)

Aikido’s October 23 analysis, updated October 24, describes exposure through outbound responses and middleware that decompresses inbound requests. A URL preview worker, crawler or remote-content fetcher deserves attention alongside the public server. This does not mean all HTTP traffic is vulnerable: the affected decoder and a path carrying attacker-controlled compressed data must be considered together. [Research analysis](https://www.aikido.dev/blog/python-packages-vulnerable-node2shell-brotli-cve-2026-111497)

Which Python versions should you check?

| Python package | Affected range in the reviewed advisory | Patched version |
|---|---|---|
| Brotli | >=1.0.3, <1.2.1 | 1.2.1 |
| brotlicffi | >=1.0.3, <1.2.1.0 | 1.2.1.0 |

Source: [GitHub advisory, reviewed October 23](https://github.com/advisories/GHSA-9v8h-qqgm-4m35). These are package-specific mappings, not a rule that every vendor build with an older-looking version is unpatched.

Google’s upstream Brotli 1.2.1 release explicitly names this CVE. The brotlicffi 1.2.1.0 changelog says it incorporates that fixed library. It also tightens handling of trailing bytes after a complete Brotli stream, rejecting some previously tolerated input. Include representative compressed-response and request-body behavior in regression checks. [Upstream release](https://github.com/google/brotli/releases/tag/v1.2.1) · [brotlicffi changelog](https://pypi.org/project/brotlicffi/1.2.1.0/)

Check the interpreter that serves the workload

For a read-only package inventory, run `python -m pip show Brotli brotlicffi` using the interpreter or virtual environment that actually runs the application. Repeat it for relevant deployed workers and container images. Record the interpreter path with the result so an output from a developer laptop cannot be mistaken for production evidence.

A package-not-found result applies to that interpreter’s package inventory. It does not clear a separate worker, another image, a native library bundled into another runtime, or the wider platform. Conversely, finding an affected package is a reason to remediate; establishing an actual attack path requires understanding which code processes untrusted compressed input.

For example, imagine a preview worker whose HTTP client gained optional Brotli support through a transitive dependency. The main web server might never decompress an incoming request, yet the worker can still decode remote responses. Track the worker’s environment and dependency lock, rather than stopping after checking the frontend service.

Patch, rebuild and verify

• Upgrade affected packages already installed through your normal dependency workflow. Do not add an absent optional decoder merely to apply this fix.
• Update dependency constraints and lockfiles, then rebuild affected images and bundled artifacts. A changed manifest does not update an already running process.
• Deploy and restart the relevant services and workers, then re-read installed versions in those workloads.
• For distribution-managed packages, check the vendor’s security advisory and backport status instead of relying only on upstream version comparisons.
• Record the service owner, package evidence, decoder path, build identifier, deployment time and smoke-test result.

An inbound filter does not cover a worker receiving a remote response. Aikido also cautions that removing br from Accept-Encoding alone is insufficient when a server can return Brotli data anyway and the client still decodes it. Any temporary decoding restriction must act before the vulnerable processing step; it should not be treated as equivalent to a verified patch. [Research analysis](https://www.aikido.dev/blog/python-packages-vulnerable-node2shell-brotli-cve-2026-111497)

Refresh scanner evidence

The advisory checked for this article now maps both pip packages. Older reports that scanners cannot flag them should not be repeated as a current universal fact. Refresh advisory data and inspect the tool’s environment coverage, while retaining the manual inventory. This article does not claim that a particular scanner was tested or that an empty alert list proves the deployment is clear. [Current package mappings](https://github.com/advisories/GHSA-9v8h-qqgm-4m35)

Sources

• Node.js security notice, October 21: https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
• GitHub advisory, reviewed October 23: https://github.com/advisories/GHSA-9v8h-qqgm-4m35
• Google Brotli 1.2.1 release: https://github.com/google/brotli/releases/tag/v1.2.1
• brotlicffi 1.2.1.0 changelog: https://pypi.org/project/brotlicffi/1.2.1.0/
• Brotli 1.2.1 package: https://pypi.org/project/brotli/1.2.1/
• urllib3 documentation: https://urllib3.readthedocs.io/en/stable/advanced-usage.html#brotli-encoding
• Aikido analysis, updated October 24: https://www.aikido.dev/blog/python-packages-vulnerable-node2shell-brotli-cve-2026-111497