CVE-2026-22776: cpp-httplib DoS Vulnerability

CVE-2026-22776 Overview

CVE-2026-22776 is a Denial of Service (DoS) vulnerability in cpp-httplib, a C++11 single-file header-only cross platform HTTP/HTTPS library. Prior to version 0.30.1, the library contains an unsafe handling mechanism for compressed HTTP request bodies when using Content-Encoding types such as gzip or br (Brotli). The vulnerability stems from the library validating the payload_max_length parameter against the compressed data size received from the network, while failing to impose any limits on the size of decompressed data stored in memory.

Critical Impact

Attackers can send small, highly compressed payloads that expand to massive amounts of data when decompressed, causing memory exhaustion and service unavailability on affected servers.

Affected Products

• cpp-httplib versions prior to 0.30.1
• Applications and services using vulnerable cpp-httplib versions for HTTP/HTTPS handling
• Any server-side implementation accepting compressed request bodies via cpp-httplib

Discovery Timeline

• 2026-01-12 - CVE CVE-2026-22776 published to NVD
• 2026-01-13 - Last updated in NVD database

Technical Details for CVE-2026-22776

Vulnerability Analysis

This vulnerability is classified as CWE-409 (Improper Handling of Highly Compressed Data), commonly known as a "decompression bomb" or "zip bomb" attack. The root issue lies in the asymmetric validation of payload sizes where the library only validates the size of incoming compressed data against the configured payload_max_length threshold.

When a client sends a compressed HTTP request body with Content-Encoding headers (such as gzip or br), the cpp-httplib server validates that the compressed payload size meets the configured limits. However, once validation passes, the library proceeds to decompress the entire payload into memory without any safeguards on the resulting decompressed size. This creates a significant attack surface where a malicious actor can craft a small compressed payload (passing size validation) that decompresses to gigabytes of data, rapidly exhausting server memory resources.

The vulnerability is exploitable remotely over the network without any authentication requirements, making it particularly dangerous for internet-facing services. An attacker requires no special privileges or user interaction to trigger this condition.

Root Cause

The root cause is the absence of decompressed size validation in the HTTP request body handling code. The library implements payload_max_length checks only on the incoming compressed data stream, creating a fundamental disconnect between what is validated (compressed size) and what consumes resources (decompressed size). This architectural oversight allows compression ratios that can exceed 1000:1 in carefully crafted payloads, enabling attackers to bypass size limits while causing massive memory allocation.

Attack Vector

The attack vector is network-based, requiring an attacker to send a crafted HTTP request to a vulnerable cpp-httplib server. The attack flow is as follows:

1. Attacker crafts a highly compressed payload (e.g., a gzip file containing repetitive data patterns)
2. Attacker sends an HTTP request with Content-Encoding header set to the appropriate compression type
3. The server receives the small compressed payload and validates it against payload_max_length
4. Validation passes because the compressed size is within limits
5. The server decompresses the payload, allocating potentially gigabytes of memory
6. Memory exhaustion occurs, causing service degradation or complete denial of service

The vulnerability can be exploited by sending HTTP requests with Content-Encoding headers such as gzip or br, where the compressed payload is small enough to pass validation but decompresses to an amount of data that exhausts available memory. See the GitHub Security Advisory for additional technical details.

Detection Methods for CVE-2026-22776

Indicators of Compromise

• Unusual memory consumption spikes on servers running cpp-httplib-based applications
• High volume of HTTP requests with Content-Encoding: gzip or Content-Encoding: br headers
• Server crashes or out-of-memory (OOM) kills in application logs
• Abnormally small request payloads paired with high memory allocation in decompression routines

Detection Strategies

• Monitor memory usage patterns for sudden spikes correlated with incoming HTTP requests
• Implement network-level detection for requests with Content-Encoding headers and suspiciously small payload sizes
• Deploy application performance monitoring (APM) to track decompression operations and their memory impact
• Use SentinelOne's behavioral AI to detect resource exhaustion patterns indicative of DoS attacks

Monitoring Recommendations

• Enable detailed logging for HTTP request processing including Content-Encoding headers and payload sizes
• Configure alerting thresholds for memory utilization on servers running cpp-httplib applications
• Implement rate limiting on endpoints that accept compressed request bodies
• Monitor for process restarts or OOM events in container orchestration systems

How to Mitigate CVE-2026-22776

Immediate Actions Required

• Upgrade cpp-httplib to version 0.30.1 or later immediately
• Audit all applications using cpp-httplib to identify vulnerable deployments
• Implement upstream rate limiting and request size validation at load balancer or WAF level
• Consider temporarily disabling support for compressed request bodies if patching is not immediately possible

Patch Information

The vulnerability has been addressed in cpp-httplib version 0.30.1. The fix is available in commit 2e2e47bab1ae6a853476eecbc4bf279dd1fef792. Users should update their single-header include file to the patched version. For applications using package managers, ensure the updated version is pulled and the application is rebuilt.

Additional information is available in the GitHub Security Advisory GHSA-h934-98h4-j43q.

Workarounds

• Implement a reverse proxy or WAF that validates and limits decompressed payload sizes before forwarding requests
• Configure aggressive memory limits (cgroups/ulimits) on application containers to prevent complete host memory exhaustion
• Disable Content-Encoding support at the application level if compressed request bodies are not required for business functionality
• Deploy request throttling to limit the rate of requests with compression headers from individual sources

# Example: Configure nginx to limit request body size (upstream protection)
client_max_body_size 10m;
client_body_buffer_size 128k;

# Example: Set memory limits for containerized applications
# docker-compose.yml
# deploy:
#   resources:
#     limits:
#       memory: 512M