CVE-2026-29076
Stack Overflow in cpp-httplib via Malicious Multipart Filename* Parsing
Publication date: 2026-03-07
Last updated on: 2026-03-09
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| yhirose | cpp-httplib | to 0.37.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-1333 | The product uses a regular expression with an inefficient, possibly exponential worst-case computational complexity that consumes excessive CPU cycles. |
| CWE-674 | The product does not properly control the amount of recursion that takes place, consuming excessive resources, such as allocated memory or the program stack. |
Attack-Flow Graph
AI Powered Q&A
How can this vulnerability impact me? :
This vulnerability can cause a denial of service (DoS) on servers using vulnerable versions of cpp-httplib (prior to 0.37.0).
An attacker can crash the server by sending a single malicious HTTP POST request with a crafted multipart/form-data body containing a large filename* parameter. This triggers a stack overflow due to deep recursion in the regex engine, causing the server process to crash (SIGSEGV).
The crash results in loss of all in-flight requests and requires an external restart of the server, potentially causing downtime and service disruption.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for server crashes (SIGSEGV) or denial of service symptoms when processing HTTP POST requests with multipart/form-data containing a crafted filename* parameter in the Content-Disposition header.
A practical detection method is to test the vulnerable endpoint (e.g., /upload) by sending a specially crafted HTTP POST request with a very long or maliciously crafted filename* parameter to see if the server crashes or becomes unresponsive.
An example approach is to use a script similar to the provided proof of concept exploit (e.g., send_exploit.py) that sends a POST request with a large filename* value to trigger the stack overflow.
On the system, you can also check logs for segmentation faults or crashes related to the cpp-httplib server process.
No specific command-line commands are provided in the resources, but network traffic capture tools like tcpdump or Wireshark can be used to inspect multipart/form-data POST requests for suspiciously long filename* parameters.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade the cpp-httplib library to version 0.37.0 or later, where the vulnerability has been fixed by replacing the vulnerable std::regex parsing with a safe manual parser.
If upgrading is not immediately possible, consider implementing strict input size limits on multipart Content-Disposition headers, especially the filename* parameter, to prevent excessively long inputs that trigger stack overflow.
Monitor and restrict incoming HTTP POST requests with multipart/form-data to detect and block suspiciously large or malformed filename* parameters.
Restart the server if it crashes due to this vulnerability, but note that this is only a temporary measure until the patch is applied.
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': "CVE-2026-29076 is a vulnerability in the cpp-httplib C++ library that occurs when parsing multipart form-data headers, specifically the Content-Disposition header's filename* parameter. The library used std::regex from libstdc++ to parse RFC 5987 encoded filenames, but this regex engine uses deep recursive backtracking that consumes one stack frame per input character."}, {'type': 'paragraph', 'content': 'An attacker can send a specially crafted HTTP POST request with a very long or maliciously crafted filename* parameter that triggers uncontrolled stack growth, causing a stack overflow and crashing the server process (SIGSEGV). This results in a denial of service.'}, {'type': 'paragraph', 'content': 'The issue was fixed in version 0.37.0 by replacing the regex-based parser with a custom, non-recursive parser that safely handles the Content-Disposition header and UTF-8 encoded filenames without risking stack overflow.'}] [1, 3]