CVE-2026-46527: cpp-httplib Remote DoS via Malformed X-Forwarded-For Header

Technical summary

The vulnerability exists in cpp-httplib's proxy IP parsing logic. When Server::set_trusted_proxies() is configured with one or more trusted proxy addresses, the library processes incoming X-Forwarded-For headers through get_client_ip(). If the header value fails to parse into any valid IP segments, the resulting std::vector remains empty. The code then calls front() on this empty container, triggering undefined behavior in C++. On most systems, this manifests as a segmentation fault and process termination. Sanitizer-enabled builds explicitly detect and report the out-of-bounds access.

Business impact

Affected applications become vulnerable to remote denial-of-service attacks that require no authentication. An attacker can crash the HTTP server by sending a single malformed request, disrupting service availability. The impact is particularly severe for always-on services, APIs, and microservices that rely on cpp-httplib for HTTP handling and have trusted proxy lists configured—common in containerized and load-balanced deployments.

Affected systems

cpp-httplib versions prior to 0.44.0 are affected. The vulnerability only manifests in deployments where Server::set_trusted_proxies() has been called with a non-empty list. Applications that do not use proxy trust configuration or have upgraded to 0.44.0 or later are not vulnerable.

Exploitability

Exploitability is straightforward. The attack requires only network access and knowledge that a target is running vulnerable cpp-httplib with proxy trust enabled. No authentication, user interaction, or sophisticated payload crafting is necessary—a malformed X-Forwarded-For header suffices. The CVSS 3.1 score of 7.5 (HIGH) reflects the low attack complexity and network accessibility, moderated by the availability-only impact and configuration prerequisite.

Remediation

Upgrade cpp-httplib to version 0.44.0 or later. The fix adds proper bounds checking before accessing the IP vector, eliminating the undefined behavior. Organizations should verify that their build integrates the patched header-only library and redeploy affected applications.

Patch guidance

Since cpp-httplib is header-only, patching requires obtaining the updated header file from the official yhirose/cpp-httplib repository (verify version 0.44.0 or later) and rebuilding dependent applications. There is no binary package or runtime patch; the fix is integrated at compile time. Review your dependency management and CI/CD pipeline to ensure the new version is pulled during next builds, then redeploy.

Detection guidance

Monitor application logs and system metrics for unexpected process crashes or exit codes when the application receives HTTP requests. Network-level detection can identify X-Forwarded-For headers with malformed or empty IP values; alert on such patterns if your proxy-enabled deployment receives them. Sanitizer-enabled builds (ASAN, UBSan) will generate explicit diagnostics upon exploitation. In production, canary deployments of the patched version can validate the fix before full rollout.

Why prioritize this

This is a HIGH-severity denial-of-service vulnerability affecting availability. Prioritize patching if your organization uses cpp-httplib with trusted proxy configuration in production, especially in microservices or containerized environments where availability is critical. The low attack complexity and network accessibility increase urgency. However, applications without proxy trust enabled face no risk and can deprioritize this patch accordingly.

Risk score, explained

CVSS 3.1 score 7.5 reflects a HIGH-severity availability impact (process crash) accessible over the network with no authentication or user interaction required. The score is not higher because the attack only affects availability (not confidentiality or integrity) and requires a specific configuration prerequisite (trusted proxies enabled). Organizations relying on cpp-httplib for public-facing APIs should treat this as urgent; internal-only deployments may accept slightly longer remediation windows.

Frequently asked questions