CVE-2026-22776: Remote Decompression Bomb Vulnerability in cpp-httplib Enables High-Impact Denial of Service

CVE: CVE-2026-22776
Product: cpp-httplib (a popular single-header C++ library for building HTTP/HTTPS clients and servers)
Severity: High
CVSS (v4.0): ~8.7 (High)
Impact: Remote Denial of Service (DoS) via decompression bomb
Exploitability: Remote, doesn’t require authentication
Official Fix/Patch: https://github.com/yhirose/cpp-httplib/releases/tag/v0.30.1

What This Vulnerability Is

cpp-httplib allows applications to accept compressed HTTP request bodies (for example, requests that use Content-Encoding: gzip). When a client sends compressed data, the library decompresses it before handing it to the application.

The bug in versions before 0.30.1 checks the size of the compressed bytes but does not limit how big the data becomes after decompression. That means someone can send a tiny compressed payload that expands to hundreds of megabytes or more when decompressed. The server tries to inflate it into memory and ends up consuming excessive RAM, leading to crashes, frozen services, or CPU exhaustion.

This kind of attack is often called a “decompression bomb.”

How It Could Be Exploited

A vulnerable server built with cpp-httplib exposes an endpoint that accepts HTTP POST/PUT requests with compressed bodies (gzip, deflate, br, etc.).
The attacker crafts a special compressed payload. On disk or over the network the data is small, but once decompressed it balloons into a huge block of text/bytes.
The server receives the compressed body, sees it’s under the expected compressed size limit, and begins decompressing it in memory.
During decompression, the server allocates large amounts of RAM, eventually overrunning its available memory or hitting CPU spikes.
The application process stalls or crashes due to memory exhaustion, leading to a Denial of Service.

This doesn’t require any credentials or complex handshake — a single HTTP request can trigger it.

Is There a Public Exploit or PoC?

There is no widely trusted public exploit code published by major researchers or vendors at this time. That doesn’t mean it’s not exploitable — only that no polished proof-of-concept has been released to the public.

However, generating a decompression bomb is conceptually straightforward: you create a compressed file with a tiny compressed size but with massive repeated content once inflated. Such payloads for testing should only be used in isolated lab environments and never against production systems or systems you do not own.

Example of how this concept works (for educational use):

Use a tool like gzip or brotli to compress a file that contains repeated large patterns (e.g., tens of megabytes of the same byte repeated).
Send that compressed data as the HTTP request body with the appropriate Content-Encoding header to the vulnerable service.
In a controlled environment, observe the server’s memory usage and behavior.

How to Detect If Someone Is Trying This

Detecting this kind of attack focuses on behavioral and resource usage patterns, because the network signatures alone don’t show the danger until decompression happens.

1. At the Application Level

Monitor your application logs or monitoring system for:

Sudden spikes in memory usage tied to specific requests.
Requests that take unusually long to process compared to normal traffic.
Errors like out-of-memory exceptions or warnings from your HTTP stack.
Multiple compressed requests coming from the same client IP in a short timeframe.

A useful approach is to correlate:

high memory usage
+
unusually long request processing time
+
Content-Encoding header indicating compression

2. At the Host/Container Level

Watch for:

Processes consuming dramatically more RAM shortly after receiving a request.
OOM (Out Of Memory) kills logged by the OS.
Repeated service restarts.

If you have container limits, look for containers hitting their memory ceilings.

3. At the Network Level

Standard IDS/IPS can log:

HTTP requests with Content-Encoding: gzip, deflate, or br.
Requests where compressed size (Content-Length) is very small.
Traffic patterns where many such requests come from unexpected sources.

But remember: network logs won’t show decompressed size, so you need to pair network indicators with application/host telemetry.

Sample Detection Logic

Below are conceptual rules you can adapt to SIEM or monitoring systems:

SIEM Rule (Pseudo-Logic)

IF
    HTTP request has Content-Encoding in [gzip, br, deflate]
    AND request body Content-Length < 20 KB
    AND process memory usage increased > 50 MB within 1 min of request
THEN
    Alert: High risk of decompression DoS attempt

This isn’t a perfect signature — adjust sizes and thresholds to match normal traffic and memory usage of your environment.

Defensive Strategies

Immediate / Short-Term

Block compressed requests at the edge: If your service does not need to accept compressed client bodies, drop or reject Content-Encoding requests at your load balancer, WAF, or reverse proxy.
Rate-limit compressed requests: Even if you must support compression, aggressively limit how many such requests a client can make.
Enforce resource limits: Use container memory limits or cgroups so a single process can’t consume all host memory.

Medium / Long-Term

Upgrade cpp-httplib to v0.30.1 or later (fixed upstream). This adds proper caps on decompressed size.
Instrument memory usage per request so you can alert before the whole service goes down.
Track patterns over time: repeated attempts from the same IP, especially from unusual locations, may indicate targeted abuse.

Official Fix / Patch

The only official patch is the upstream library release that corrects the decompression behavior. You should update all affected builds to cpp-httplib v0.30.1 or later.

Official release with the fix:
➡️ https://github.com/yhirose/cpp-httplib/releases/tag/v0.30.1

If your product vendor or Linux distro packages this library, monitor their security announcements and apply their updates as soon as they’re available.

Final Takeaway

Inventory all services and binaries that use cpp-httplib (remember that vendored single-header copies may exist deep in your codebase).
Update to v0.30.1 or later wherever cpp-httplib is used.
Block/reject compressed request bodies at your edge if not needed.
Monitor memory growth and request timing in your telemetry.
Alert on combinations of compressed requests + memory spikes.
Test safely in a lab with crafted compressed payloads to confirm your environment’s behavior (only in isolated, controlled setups).