CVE-2026-103930 in cpp-httplib
Summary
by MITRE • 10/15/2026
cpp-httplib is a C++ header-only HTTP/HTTPS library. From 0.29.0 until 0.51.0, Client::open_stream in httplib.h accepts a caller-controlled path that reaches detail::write_request_line() without the detail::encode_path() protection used by the ordinary buffered request path. Raw carriage-return and line-feed bytes in the path can therefore split the outbound HTTP/1.1 request line and inject attacker-shaped request metadata. Exploitation requires an embedding application to pass remote user input into the open_stream path and a backend or intermediary that interprets the injected bytes; the established impact is modification of backend-visible request data, not direct confidentiality or availability impact. This issue is fixed in version 0.51.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The cpp-httplib library serves as a widely adopted header-only HTTP and HTTPS client implementation for C++ applications. Within the specific versions ranging from 0.29.0 through 0.51.0, a critical architectural inconsistency exists in how different request paths handle input validation. Specifically, the Client::open_stream method accepts a path parameter that is passed directly to detail::write_request_line() without undergoing the necessary sanitization procedures applied by other parts of the library. This discrepancy creates a vector for HTTP Request Smuggling or Header Injection attacks when user-controlled data is processed through this specific API endpoint.
The technical root cause lies in the absence of encoding protections during the construction of the initial request line. In standard buffered request paths, the detail::encode_path() function is invoked to sanitize input by escaping special characters that could disrupt HTTP protocol syntax. However, the open_stream path bypasses this safeguard entirely. Consequently, if an embedding application passes remote user input directly into the path argument of open_stream, raw carriage return and line feed bytes are transmitted unmodified within the HTTP/1.1 request line. This allows an attacker to split the request line, effectively injecting arbitrary headers or metadata that appear legitimate to downstream intermediaries but deviate from expected protocol structure when viewed by the final backend server.
The operational impact of this vulnerability is primarily centered on data integrity and trust boundary violations rather than direct confidentiality breaches or service availability disruptions. Successful exploitation requires two conditions: first, an embedding application must pass untrusted remote input into the open_stream path parameter; second, there must be a backend server or network intermediary that interprets HTTP messages with strict parsing rules susceptible to request splitting. When these conditions are met, the attacker can manipulate backend-visible request data. This may lead to security bypasses if access controls rely on headers injected via this flaw, cache poisoning in caching proxies, or confusion between multiple servers handling sequential requests within a connection pool.
This vulnerability aligns with CWE-74, which describes Injection flaws where untrusted data is sent to an interpreter as part of a command or query. It also maps to MITRE ATT&CK technique T1071, Application Layer Protocol: Web Protocols, specifically regarding the manipulation of HTTP headers and request structures for malicious purposes. The lack of consistent input validation across different code paths within the same library represents a common pattern in complex software systems where security controls are not uniformly applied.
To mitigate this risk, organizations using cpp-httplib must upgrade to version 0.51.0 or later, which resolves the encoding omission by ensuring that all request construction paths apply appropriate path encoding before transmission. For applications unable to immediately update their dependencies, a temporary mitigation involves implementing strict input validation at the application layer. Developers should reject any HTTP method requests containing raw carriage return (ASCII 13) or line feed (ASCII 10) characters in URL paths prior to invoking open_stream. Additionally, employing Web Application Firewalls with robust HTTP parsing capabilities can help detect and block malformed request lines that exhibit signs of injection attempts before they reach the backend infrastructure.