CVE-2026-22776: 
Homebrew vulnerability analysis and mitigation

CVE-2026-22776 is a Denial of Service (DoS) vulnerability — commonly referred to as a "zip bomb" or decompression bomb attack — in cpp-httplib, a C++11 single-file header-only cross-platform HTTP/HTTPS library. The vulnerability affects all versions prior to 0.30.1 and was published on January 12, 2026, with a patch released in version 0.30.1. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-409 (Improper Handling of Highly Compressed Data / Data Amplification) and CWE-400 (Uncontrolled Resource Consumption). In the Server::read_content() function, the library correctly validates payload_max_length_ against the compressed data size received over the network, but the decompressed body is appended to req.body without checking against payload_max_length_. As a result, the effective limit on decompressed data defaults to req.body.max_size() — approximately 4 quintillion bytes on 64-bit systems. The fix, applied in commit 2e2e47b, adds a check if (req.body.size() + n > payload_max_length_) before appending decompressed data, causing the server to return HTTP 400 Bad Request when the limit is exceeded (GitHub Advisory, GitHub Commit).

Successful exploitation causes the target server to exhaust all available RAM and crash via an OOM (Out-of-Memory) kill, resulting in complete service unavailability. There is no impact on confidentiality or integrity — the vulnerability is purely an availability issue. Any application embedding cpp-httplib versions prior to 0.30.1 and accepting HTTP requests with compressed bodies (e.g., Content-Encoding: gzip or br) from untrusted sources is at risk of being crashed by a single malicious request (GitHub Advisory).

A proof-of-concept (PoC) exploit script is publicly referenced in the GitHub security advisory (hosted at a private repository Hritik14/httplib-dos), demonstrating a Python-based attack that generates a ~4.86 MB gzip payload that decompresses to 5 GB, crashing a memory-limited server. No authentication or user interaction is required, making this trivially exploitable by any network-accessible attacker. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.042% (GitHub Advisory, Feedly).

1. Reconnaissance: Identify services using cpp-httplib versions prior to 0.30.1 that accept HTTP POST requests with compressed bodies. This may be identified through banner analysis, open-source dependency scanning, or software composition analysis tools.
2. Generate a zip bomb payload: Create a highly compressed gzip payload using a script (e.g., Python with the gzip module) that compresses several gigabytes of null bytes (\x00) into a small file (e.g., ~5 MB compressed → 5 GB decompressed).

   import gzip, io
   buf = io.BytesIO()
   with gzip.GzipFile(fileobj=buf, mode='wb', compresslevel=9) as f:
       chunk = b'\0' * (100 * 1024 * 1024)
       for _ in range(50):  # 5 GB total
           f.write(chunk)
   payload = buf.getvalue()

3. Craft the malicious HTTP request: Send an HTTP POST request to any endpoint on the target server with the headers Content-Encoding: gzip and Content-Length set to the compressed payload size.
4. Transmit the payload: Send the compressed payload over a raw TCP socket or HTTP client. The server will begin decompressing the body into memory without enforcing payload_max_length_ on the decompressed size.
5. Trigger OOM crash: As the server decompresses the payload, RAM is exhausted and the process is killed by the OS OOM killer, causing a denial of service (GitHub Advisory).

• Network: Inbound HTTP POST requests with Content-Encoding: gzip (or br) headers and unusually small Content-Length values (e.g., a few MB) to any endpoint; connections that remain open for an extended period while transmitting compressed data.
• Process/System: Sudden spike in memory consumption by the cpp-httplib server process immediately following receipt of a compressed HTTP request; OOM kill events in system logs (dmesg or /var/log/syslog) referencing the server process.
• Logs: Application or web server logs showing a POST request with Content-Encoding: gzip followed by an abrupt process termination or absence of a response log entry; HTTP 400 responses (if patched) to requests with large decompressed bodies.
• File System: Presence of suspicious gzip files or attack scripts (e.g., Python scripts generating large null-byte payloads) on attacker-controlled systems if post-compromise forensics are performed (GitHub Advisory).

Upgrade cpp-httplib to version 0.30.1 or later, which enforces payload_max_length_ against the decompressed body size, correctly rejecting oversized payloads with HTTP 400 Bad Request. Fedora and openSUSE packages have received updated builds incorporating the fix. As a temporary workaround where upgrading is not immediately possible, consider placing a reverse proxy (e.g., nginx) in front of the application that enforces strict request body size limits and rejects or limits compressed content before it reaches the cpp-httplib server. Prioritize patching for any instance of cpp-httplib exposed to untrusted network traffic (GitHub Commit, GitHub Advisory, Red Hat Bugzilla).

Red Hat tracked the vulnerability via Bugzilla and assessed it as high severity, with dependent package tracking across multiple Fedora and RHEL components. Fedora issued updated packages for cpp-httplib, and openSUSE published a security announcement addressing the issue. A blog post on infinitsec.net covered the vulnerability with technical detail shortly after disclosure. Social media activity on Bluesky noted the CVE publication. Overall community reaction was measured, consistent with a library-level DoS vulnerability with a straightforward patch (Red Hat Bugzilla, Red Hat CVE).