CVE-2026-21428
Yhirose Cpp-Httplib ≤ 0.30.0
Raw vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2026-21428 is a high-severity CRLF Injection (CWE-93) vulnerability in Yhirose Cpp-Httplib. Its CVSS base score is 7.7 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Content Injection (T1659); ranked at the 31th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-21428 affects cpp-httplib, a C++11 single-file header-only cross-platform HTTP/HTTPS library, in versions prior to 0.30.0. The vulnerability resides in the `write_headers` function, which fails to validate user-supplied header values for carriage return (CR) and line feed (LF) characters. This oversight allows malicious header values to escape their intended lines, enabling header injection. The issue is classified under CWE-93 (Improper Neutralization of CRLF Sequences) with a CVSS v3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N), indicating high integrity impact from network-accessible exploitation without privileges.
Remote attackers can exploit this vulnerability by supplying crafted HTTP headers containing CR/LF sequences. Successful exploitation allows adding arbitrary extra headers, unexpectedly modifying the request body, and potentially triggering server-side request forgery (SSRF) attacks. The SSRF risk escalates when cpp-httplib is used with servers supporting HTTP/1.1 pipelining, such as Spring Boot or Python Twisted, as attackers can forge requests to internal or unauthorized endpoints.
The cpp-httplib project addresses this in version 0.30.0, which includes a fix via commit 98048a033a532ff22320ce1d11789f8d5710dfcd. Security practitioners should upgrade to v0.30.0 or later. Additional details are available in the GitHub security advisory (GHSA-wpc6-j37r-jcx7) and release notes.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-0026
Vulnerability Data
cpp-httplib is a C++11 single-file header-only cross platform HTTP/HTTPS library. Prior to version 0.30.0, the ``write_headers`` function does not check for CR & LF characters in user supplied headers, allowing untrusted header value to escape header lines. This vulnerability allows…
more
attackers to add extra headers, modify request body unexpectedly & trigger an SSRF attack. When combined with a server that supports http1.1 pipelining (springboot, python twisted etc), this can be used for server side request forgery (SSRF). Version 0.30.0 fixes this issue.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V4.2.4
Mitigating Controls (NIST 800-53 r5) AI
Input validation directly stops untrusted data containing CRLF sequences from reaching the component that treats CRLF as a delimiter.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require input neutralization and validation to block CRLF injection.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect CRLF flaws but does not itself implement the neutralization.
Secure development lifecycle mandates input validation and output encoding that directly prevents CRLF injection.
Application security requirements include rules for neutralizing special characters such as CRLF in inputs.
Secure architecture principles encourage safe handling of untrusted data but do not prescribe specific CRLF controls.
Secure coding standards explicitly require neutralization of CRLF sequences, fully addressing this weakness.