CVE-2026-28435: 
Homebrew vulnerability analysis and mitigation

CVE-2026-28435 is a payload size limit bypass vulnerability in cpp-httplib, a C++11 single-file header-only cross-platform HTTP/HTTPS library. The flaw allows unauthenticated remote attackers to bypass the configured Server::set_payload_max_length() limit by sending gzip-compressed (or otherwise encoded) request bodies that decompress to sizes far exceeding the configured limit when processed via the HandlerWithContentReader (streaming ContentReader) path. All versions prior to 0.35.0 are affected. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause (CWE-400: Uncontrolled Resource Consumption; CWE-409: Improper Handling of Highly Compressed Data) lies in how detail::prepare_content_receiver applies the payload size limit. When decompression is enabled, the limit check in read_content_* functions counts compressed bytes read from the network socket, not the decompressed output bytes emitted to the application receiver. The non-streaming path that builds req.body includes an explicit decompressed-size guard (zip-bomb protection), but the streaming ContentReader path does not — the application-provided receiver receives decompressed chunks with no library-enforced size cap. An attacker exploits this by sending a POST/PUT/PATCH/DELETE request with Content-Encoding: gzip and a tiny Content-Length (e.g., ~290 bytes compressed) that inflates to hundreds of kilobytes or more, bypassing the configured limit entirely. A complete C++ server and Python client proof-of-concept is publicly available in the official security advisory (GitHub Advisory, Fix Commit).

Successful exploitation causes the server to process decompressed request bodies far exceeding the configured payload size limit, resulting in excessive CPU usage from decompression work and increased memory consumption depending on how the application processes the data. In constrained environments or under high concurrency, this can lead to denial of service (DoS) through resource exhaustion. There is no confidentiality or integrity impact — the vulnerability is limited to availability (GitHub Advisory).

A complete, runnable proof-of-concept (C++ server + Python client) is publicly available in the official GitHub Security Advisory, demonstrating the bypass with a 256 KB payload compressed to ~290 bytes (GitHub Advisory). Exploitation has been reported by multiple sources including security blogs, and the vulnerability requires no authentication, no privileges, and no user interaction. The EPSS score is approximately 0.04% (low probability of near-term exploitation), and the vulnerability is not currently listed in the CISA KEV catalog. No specific threat actor attribution has been reported.

1. Reconnaissance: Identify HTTP/HTTPS services built with cpp-httplib versions ≤ 0.34.0 that expose endpoints using HandlerWithContentReader (streaming ContentReader) and have CPPHTTPLIB_ZLIB_SUPPORT enabled.
2. Prepare decompression bomb payload: Create a large raw payload (e.g., 256 KB of repeated bytes) and gzip-compress it to a small size (e.g., ~290 bytes at maximum compression level): raw = b'A' * (256 * 1024); gz = gzip.compress(raw, compresslevel=9).
3. Craft malicious HTTP request: Construct an HTTP POST (or PUT/PATCH/DELETE) request targeting a streaming endpoint with headers Content-Encoding: gzip and Content-Length set to the compressed payload size (~290 bytes).
4. Send request: Transmit the crafted request to the target server: POST /stream HTTP/1.1\r\nContent-Encoding: gzip\r\nContent-Length: 290\r\n\r\n<gz_payload>.
5. Trigger bypass: The server decompresses the payload inside the ContentReader callback without enforcing payload_max_length_ on decompressed bytes, delivering 256 KB+ to the application handler despite a configured 64 KB limit.
6. Achieve DoS: Repeat requests at high concurrency to exhaust server CPU and memory resources, causing denial of service (GitHub Advisory).

• Network: HTTP POST/PUT/PATCH/DELETE requests with Content-Encoding: gzip (or other supported encodings) and a very small Content-Length (e.g., < 1 KB) targeting endpoints that use streaming ContentReader; high volume of such requests from a single source IP.
• Logs: Server access logs showing requests with small Content-Length values but disproportionately high processing times or memory spikes; application-level logs printing decompressed body sizes far exceeding the configured payload_max_length.
• Process/System: Sudden spikes in CPU or memory usage on the cpp-httplib server process correlating with incoming compressed HTTP requests; OOM (out-of-memory) events or process crashes under high concurrency.

Upgrade cpp-httplib to version 0.35.0 or later, which enforces payload_max_length_ on decompressed output within the ContentReader path by tracking decompressed bytes and aborting with HTTP 413 Payload Too Large if the limit is exceeded (Fix Commit). If immediate patching is not possible, apply one of the following workarounds: (1) reject requests with Content-Encoding headers on endpoints that use ContentReader; (2) implement an explicit decompressed-byte counter inside the application's ContentReader callback and abort once a cap is reached; or (3) enforce request size limits at the network boundary (e.g., reverse proxy or WAF) before traffic reaches the cpp-httplib server (GitHub Advisory).

The vulnerability was disclosed by the library maintainer (yhirose) via a GitHub Security Advisory on March 2, 2026, credited to researcher thesmartshadow (GitHub Advisory). Red Hat tracked the issue via Bugzilla and rated it high severity (Red Hat Bugzilla). Security community accounts on Bluesky and Mastodon (e.g., @thehackerwire) shared the advisory shortly after publication, and Fedora issued package updates for Fedora 42, 43, and 44. A technical blog post on securing C++ web services referencing this CVE was also published.