CVE-2026-29076: Yhirose Cpp-httplib Buffer Overflow Flaw

CVE-2026-29076 Overview

CVE-2026-29076 is a stack overflow vulnerability in cpp-httplib, a popular C++11 single-file header-only cross platform HTTP/HTTPS library. Prior to version 0.37.0, the library uses std::regex (libstdc++) to parse RFC 5987 encoded filename* values in multipart Content-Disposition headers. The regex engine in libstdc++ implements backtracking via deep recursion, consuming one stack frame per input character. An attacker can send a single HTTP POST request with a crafted filename* parameter that causes uncontrolled stack growth, resulting in a stack overflow (SIGSEGV) that crashes the server process.

Critical Impact

A remote unauthenticated attacker can crash any server using vulnerable versions of cpp-httplib by sending a single malicious HTTP POST request with a specially crafted multipart Content-Disposition header, causing a complete denial of service.

Affected Products

• yhirose cpp-httplib versions prior to 0.37.0

Discovery Timeline

• 2026-03-07 - CVE-2026-29076 published to NVD
• 2026-03-09 - Last updated in NVD database

Technical Details for CVE-2026-29076

Vulnerability Analysis

This vulnerability is classified under CWE-674 (Uncontrolled Recursion). The root cause lies in how cpp-httplib processes multipart form data headers. When parsing Content-Disposition headers containing RFC 5987 encoded filename parameters, the library relied on std::regex from libstdc++ to extract and validate the filename values.

The libstdc++ implementation of std::regex uses a backtracking algorithm that is implemented through deep recursion rather than iteration. Each character in the input string requires a new stack frame during the regex matching process. When an attacker provides a sufficiently long or specially crafted filename* parameter value, the regex engine recursively processes each character, rapidly exhausting the available stack space.

The attack requires no authentication and can be executed with a single HTTP POST request. The server process receives a SIGSEGV signal when the stack overflows, resulting in an immediate crash and denial of service to all clients.

Root Cause

The vulnerability stems from the use of std::regex with libstdc++ for parsing Content-Disposition headers. The libstdc++ regex implementation uses recursive backtracking which is vulnerable to stack exhaustion attacks. The regex pattern R"~(^Content-Disposition:\s*form-data;\s*(.*)$)~" was applied to user-controlled header content without adequate protection against pathological input that could trigger excessive recursion depth.

Attack Vector

The attack is network-based and requires no user interaction or authentication. An attacker constructs an HTTP POST request with a multipart form body containing a Content-Disposition header with a maliciously crafted filename* parameter. The parameter value is designed to maximize the recursion depth of the regex engine, typically by using a long string or specific patterns that cause exponential backtracking.

             file_.content_type =
                 trim_copy(header.substr(str_len(header_content_type)));
           } else {
-            thread_local const std::regex re_content_disposition(
-                R"~(^Content-Disposition:\s*form-data;\s*(.*)$)~",
-                std::regex_constants::icase);
-
-            std::smatch m;
-            if (std::regex_match(header, m, re_content_disposition)) {
+            std::string disposition_params;
+            if (parse_content_disposition(header, disposition_params)) {
               Params params;
-              parse_disposition_params(m[1], params);
+              parse_disposition_params(disposition_params, params);

               auto it = params.find("name");
               if (it != params.end()) {

Source: GitHub Commit de296af

The patch replaces the vulnerable std::regex_match approach with a custom parse_content_disposition function that parses the header without relying on recursive regex matching, eliminating the stack overflow risk.

Detection Methods for CVE-2026-29076

Indicators of Compromise

• Server processes crashing with SIGSEGV signals during HTTP request processing
• Core dumps showing deep stack traces in regex-related functions
• Unusual HTTP POST requests with abnormally large Content-Disposition header values
• Multiple server restarts or service interruptions without apparent cause

Detection Strategies

• Monitor for SIGSEGV signals in processes using cpp-httplib
• Implement web application firewall rules to detect abnormally long Content-Disposition headers
• Review HTTP access logs for POST requests with suspicious multipart form data patterns
• Deploy runtime protection that monitors stack usage and detects stack exhaustion attempts

Monitoring Recommendations

• Configure process monitoring to alert on unexpected crashes of HTTP services
• Implement request size and header length limits at the load balancer or reverse proxy level
• Enable crash reporting and core dump analysis for early detection of exploitation attempts
• Monitor for patterns of repeated service restarts that may indicate ongoing attack attempts

How to Mitigate CVE-2026-29076

Immediate Actions Required

• Upgrade cpp-httplib to version 0.37.0 or later immediately
• If immediate upgrade is not possible, implement request filtering at the reverse proxy level to limit Content-Disposition header sizes
• Review and audit all applications using cpp-httplib to identify affected deployments
• Enable crash monitoring and alerting for services using the vulnerable library

Patch Information

The vulnerability has been patched in cpp-httplib version 0.37.0. The fix replaces the vulnerable std::regex-based parsing with a custom parse_content_disposition function that does not rely on recursive regex matching. Users should upgrade to version 0.37.0 or later by updating their header file from the official GitHub release.

For detailed information about the security fix, refer to the GitHub Security Advisory GHSA-qq6v-r583-3h69 and the commit de296af3eb5b0d5c116470e033db900e4812c5e6.

Workarounds

• Implement a reverse proxy or WAF rule to reject requests with Content-Disposition headers exceeding a reasonable length threshold
• Limit the maximum size of multipart form data at the network edge
• Consider implementing request rate limiting to reduce the impact of potential DoS attempts
• Run vulnerable services with stack size limits and automatic restart capabilities as a temporary mitigation

# Configuration example for nginx to limit header sizes
# Add to nginx.conf or server block
large_client_header_buffers 4 8k;
client_header_buffer_size 1k;

# Limit overall request body size for multipart uploads
client_max_body_size 10m;