# HTTP2Shell: Brotli Buffer Overflow, Kubernetes Detection & Production Fix

---

*Originally published on* [*Naveed Ahmed's Engineering Blog*](https://blog.naveedkumbhar.com/http2shell/)*.*

🚨 A security vulnerability in a compression library might not sound like a major infrastructure concern.

But what happens when that library is used by applications running across hundreds of containers?

That's the concern with **HTTP2Shell (CVE-2026-111497)**, a serious out-of-bounds write vulnerability in Google's Brotli decompression library.

When affected software processes specially crafted Brotli-compressed input, it can trigger memory corruption.

Depending on the application and exploitability, potential consequences include crashes, information disclosure, or remote code execution.

For DevOps and SRE teams, the priority is identifying affected workloads, applying patches, and verifying that vulnerable components have actually been replaced.

Here's a practical breakdown.

## 1\. What Is HTTP2Shell?

Brotli is a compression algorithm used in web applications, language runtimes, and other software.

HTTP2Shell involves a memory-safety flaw in the Brotli decoder.

A vulnerable decoder may write beyond its allocated memory buffer while processing malformed compressed input.

The failure path can be summarized as:

```text
Untrusted Brotli Input
          |
          v
Vulnerable Brotli Decoder
          |
          v
Out-of-Bounds Memory Write
          |
          v
Memory Corruption
          |
          v
Potential Crash / Data Exposure / RCE
```

Despite the name HTTP2Shell, the underlying vulnerability isn't limited to HTTP/2 connections.

The important factor is whether vulnerable decoding functionality can process attacker-controlled data.

## 2\. Which Applications Are Affected?

Start by investigating applications that use potentially vulnerable Brotli implementations.

Common environments include:

- Node.js applications with affected runtime versions
- Python applications using vulnerable Brotli packages
- .NET applications using affected decompression components
- Kubernetes workloads running affected container images
- Applications with statically bundled Brotli libraries

Not every application with Brotli installed is automatically exploitable.

Actual exposure depends on the implementation and whether untrusted compressed data reaches the vulnerable decoder.

### Patched versions to check

| Technology | Fixed versions |
| --- | --- |
| Node.js 22 | 22.23.4 |
| Node.js 24 | 24.22.1 |
| Node.js 26 | 26.12.1 |
| Python Brotli | 1.2.1 |
| Python brotlicffi | 1.2.1.0 |
| .NET 8 | 8.0.33 |
| .NET 9 | 9.0.22 |
| .NET 10 | 10.0.14 |

Linux distributions may also backport security fixes without changing the upstream version number. Always verify against the relevant vendor advisory.

## 3\. Detecting HTTP2Shell in Kubernetes

If your applications run in Kubernetes, start by identifying running container images.

```bash
kubectl get pods -n production \
  -o custom-columns='POD:.metadata.name,IMAGES:.spec.containers[*].image'
```

For a Node.js workload, inspect the runtime version:

```bash
kubectl exec -n production deploy/api-gateway \
  -c app -- node -p "process.version"
```

Check the embedded Brotli version:

```bash
kubectl exec -n production deploy/api-gateway \
  -c app -- node -p "process.versions.brotli"
```

These commands help identify workloads that may need attention.

However, version output alone doesn't prove whether a workload is exploitable. Compare the installed runtime with official security advisories.

## 4\. Scan Container Images with Trivy

Container scanning can help identify vulnerable dependencies before deploying new images.

For example:

```bash
trivy image --scanners vuln \
  --severity HIGH,CRITICAL \
  registry.example.com/api-service:production
```

Replace the example image with your actual production image.

For larger environments, Software Bills of Materials (SBOMs) can help track where affected components are deployed.

Keep in mind that some embedded or statically linked libraries may require additional investigation beyond automated scanners.

## 5\. How to Fix HTTP2Shell in Production

A practical remediation process should include:

1. Identify services processing untrusted Brotli data.
2. Review the applicable vendor advisories.
3. Upgrade vulnerable libraries and runtimes.
4. Rebuild affected container images.
5. Redeploy patched workloads.
6. Verify the versions running in production.
7. Monitor application crashes and suspicious activity.

**Important:** Updating the host operating system doesn't necessarily fix vulnerable libraries bundled into existing container images.

If patching cannot happen immediately, consider temporarily disabling Brotli decompression of untrusted input where practical.

WAF and ingress filtering may reduce exposure in some environments, but they shouldn't replace patching.

An application might also decompress Brotli data from internal services, files, or other sources that bypass edge filtering.

---

## 6\. What DevOps Teams Can Learn

HTTP2Shell highlights an important software supply chain challenge.

A vulnerable dependency may be hidden inside a runtime, container image, or third-party component.

That's why production security requires more than running a vulnerability scanner once.

Teams should maintain:

- Automated dependency and container scanning
- SBOMs for critical services
- Supported runtime versions
- Reproducible container builds
- Emergency patching procedures
- Post-deployment vulnerability verification

The goal isn't simply to close a security ticket.

It's to confirm that affected production workloads are no longer running vulnerable code.

---

## 📖 Read the Complete HTTP2Shell Production Guide

I wrote a detailed technical guide covering the vulnerability's architecture, affected runtimes, Kubernetes auditing, and production mitigation strategies.

The complete article explores:

- HTTP2Shell root cause and Brotli memory corruption
- CVE-2026-111497 security impact
- Node.js, Python, and .NET remediation
- Kubernetes workload auditing
- Trivy and SBOM vulnerability detection
- Container rebuilds and deployment verification
- WAF, ingress, and CI/CD security practices

👉 [**Read the Complete HTTP2Shell: Brotli Buffer Overflow Root Cause & Production Fix**](https://blog.naveedkumbhar.com/http2shell/)

---

## Final Thoughts

A small dependency can create a serious security challenge when it's deployed across multiple applications.

HTTP2Shell is a reminder that visibility into production dependencies matters just as much as applying security patches.

**Know what's running, identify exposure, patch affected components, and verify remediation.**

💬 How does your team handle emergency vulnerability patching across Kubernetes clusters?

Do you use Trivy, SBOMs, automated dependency updates, or another approach?

Share your experience in the comments.

---

*Written by Naveed Ahmed — Lead DevOps & Platform Architect*

🌐 [Engineering Blog](https://blog.naveedkumbhar.com) | 🐙 [GitHub](https://github.com/naveedkumbhar) | 💼 [LinkedIn](https://pk.linkedin.com/in/naveedkumbhar)

🛠️ [SRE Interview Practice](https://interview.naveedkumbhar.com) | ☸️ [Kubernetes Mastery](https://k8s.naveedkumbhar.com)