CVE-2026-54919: cpp-httplib Certificate Validation Bypass with Mbed TLS and wolfSSL

Technical summary

The vulnerability stems from improper SSL/TLS certificate chain validation in cpp-httplib when the SSL backend is Mbed TLS or wolfSSL and the connection target is specified as an IP literal (IPv4 or IPv6 address) rather than a domain name. When SSLClient or Client objects perform HTTPS connections under these conditions, the certificate verification logic is bypassed. WebSocketClient exhibits complete verification bypass on the Mbed TLS backend regardless of host format. The root cause appears to be conditional logic that treats IP-literal hosts differently during certificate validation, potentially confusing hostname verification with IP validation or omitting the validation step entirely. CWE-295 (Improper Certificate Validation) categorizes this weakness.

Business impact

Organizations using cpp-httplib in production applications face exposure to man-in-the-middle attacks, particularly in environments where HTTPS is used to communicate with services identified by IP address rather than domain name. This is common in microservices architectures, internal tool infrastructure, and IoT/embedded deployments. Compromised traffic could leak authentication credentials, API keys, user data, or proprietary information. In regulated environments (healthcare, finance, payment processing), this creates compliance violations. The impact severity is elevated in scenarios where cpp-httplib is embedded in libraries or frameworks that developers may not directly control, as the vulnerability could be silently present in transitive dependencies.

Affected systems

Directly affected are applications compiled with cpp-httplib versions 0.31.0–0.46.1 when using the Mbed TLS backend, or versions 0.33.0–0.46.1 when using the wolfSSL backend, and where HTTPS client connections are made to IP-literal hosts. The vulnerability does not affect the default OpenSSL backend or non-HTTPS connections. Organizations should audit their build configurations and dependency trees to identify which applications include cpp-httplib with these specific backends enabled (via CPPHTTPLIB_MBEDTLS_SUPPORT or CPPHTTPLIB_WOLFSSL_SUPPORT preprocessor flags).

Exploitability

Exploitability requires the attacker to be positioned on the network path between the affected application and its target server (network interception capability). The CVSS vector reflects this intermediate access requirement (AC:H) but otherwise straightforward execution: no user interaction is needed, and no privileges are required. Exploitation is practical in shared network environments, compromised network infrastructure, or cloud environments where lateral traffic visibility is possible. Once positioned, the attacker can present any certificate; the validation bypass requires no additional crafting beyond a standard man-in-the-middle setup.

Remediation

Upgrade cpp-httplib to version 0.47.0 or later, which restores proper certificate validation for IP-literal hosts across both Mbed TLS and wolfSSL backends. Organizations should recompile and redeploy affected applications after upgrading. If immediate upgrade is not feasible, mitigation strategies include: (1) routing all HTTPS connections through domain names rather than IP addresses, which may allow using hostname-based certificate pinning or alternative validation logic; (2) isolating affected services to network segments where man-in-the-middle attacks are infeasible (e.g., direct dedicated links); (3) using VPN or mTLS overlays to add an additional encryption layer independent of cpp-httplib's TLS validation.

Patch guidance

Verify the current cpp-httplib version in your codebase by checking the header file version macro or git tags in your dependency. Update to version 0.47.0 or later from the official yhirose/cpp-httplib repository. After patching, rebuild all applications and libraries that statically or dynamically link cpp-httplib. Confirm the patch by reviewing the source code or release notes to ensure the certificate validation logic has been corrected. Pay special attention to projects where cpp-httplib may be vendored or pinned to an older version via build system constraints.

Detection guidance

Log and monitor HTTPS client connections made by applications using cpp-httplib, particularly those specifying IP-literal targets. Use network intrusion detection signatures to flag certificate mismatches or unexpected certificate issuers for internal IP addresses (a red flag for MITM). Review application logs for SSL/TLS handshake errors or warnings that may indicate certificate validation was bypassed. In source code, search for builds or configurations enabling CPPHTTPLIB_MBEDTLS_SUPPORT or CPPHTTPLIB_WOLFSSL_SUPPORT combined with IP-based HTTPS connection patterns. Runtime analysis tools or HSTS preloading (where applicable) can provide additional defense.

Why prioritize this

This vulnerability merits urgent prioritization because it directly undermines a core security mechanism (certificate validation) for encrypted communications. The CVSS score of 7.4 reflects high confidentiality and integrity impact, and the exploitation prerequisites (network position) are realistic in modern infrastructure. The affected versions are in widespread use, particularly in embedded and microservice contexts where Mbed TLS or wolfSSL are preferred for smaller footprint. Although not yet listed in CISA's Known Exploited Vulnerabilities catalog, the simplicity of exploitation and the sensitivity of affected applications make rapid remediation essential before public exploitation tooling emerges.

Risk score, explained

The CVSS 3.1 score of 7.4 (HIGH) reflects: (1) Network vector (AV:N) — any networked attacker can attempt exploitation; (2) High complexity (AC:H) — requires the attacker to be on the network path, a non-trivial but achievable condition; (3) No privileges or user interaction required (PR:N/UI:N); (4) High confidentiality impact (C:H) — encrypted traffic can be decrypted and read; (5) High integrity impact (I:H) — traffic can be modified; (6) No availability impact (A:N) — the service remains operational. The score does not account for likelihood of exploitation or attack surface within specific organizations, which may warrant adjustments based on your environment's reliance on IP-based HTTPS connections.

Frequently asked questions