CVE-2026-32627: 
Homebrew vulnerability analysis and mitigation

CVE-2026-32627 is a silent TLS certificate verification bypass vulnerability in cpp-httplib, a C++11 single-file header-only cross-platform HTTP/HTTPS library. When a client is configured with a proxy and set_follow_location(true), any HTTPS redirect it follows will have TLS certificate and hostname verification silently disabled on the new connection, allowing the client to accept expired, self-signed, or forged certificates without error. All versions up to and including 0.37.1 are affected; the vulnerability was disclosed on March 13, 2026, and fixed in version 0.37.2. It carries a CVSS v3.1 base score of 8.1 (High) per NVD, and 8.7 (High) per the GitHub Security Advisory (GitHub Advisory, Red Hat Bugzilla).

The root cause is CWE-295 (Improper Certificate Validation), located in ClientImpl::create_redirect_client() at lines 12762–12766 of httplib.h. When a 3xx redirect is detected and follow_location_ is enabled, the code creates a new SSLClient for the redirect target and, if a proxy is configured, unconditionally calls redirect_client.enable_server_certificate_verification(false) and redirect_client.enable_server_hostname_verification(false) — instead of copying the original client's verification settings as the non-proxy code path correctly does. Critically, setup_redirect_client() is called just before this block and copies the original client's credentials (basic auth, bearer tokens, digest auth) into the redirect client, meaning those credentials are then transmitted over an unverified TLS connection. The application receives no error, callback, or log entry indicating that verification was bypassed (GitHub Advisory).

An unauthenticated network attacker who can control the HTTP server initially contacted, operate a rogue DNS resolver, or intercept proxy traffic can redirect the client to a TLS endpoint of their choice and present any certificate. The client will complete the TLS handshake, forward all loaded credentials (basic auth, bearer tokens, digest auth), and receive attacker-modified responses — with no indication to the application that interception occurred. This results in high confidentiality and integrity impact; availability impact is not directly affected by the bypass itself. The vulnerability is particularly dangerous in corporate and IoT environments where all egress traffic is routed through a proxy, a common configuration that makes the vulnerable code path easy to reach (GitHub Advisory, Feedly).

A proof-of-concept with step-by-step reproduction instructions is publicly available in the GitHub Security Advisory, including server setup commands and a runnable client code snippet (GitHub Advisory). There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.017% (0.000170), reflecting low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires a network attacker capable of returning a redirect response (high attack complexity), but no privileges or user interaction are needed (Feedly).

1. Reconnaissance: Identify applications using cpp-httplib ≤ 0.37.1 built with SSL support (CPPHTTPLIB_OPENSSL_SUPPORT) that are configured with both a proxy and set_follow_location(true) — common in corporate and IoT environments.
2. Set up a rogue HTTP server: Stand up a plain HTTP server at an attacker-controlled host that returns a 302 redirect response pointing to an attacker-controlled HTTPS endpoint: HTTP/1.1 302 Found\nLocation: https://attacker-mitm.example.com/resource.
3. Set up a rogue TLS listener: Configure a TLS listener at the redirect target with a self-signed certificate (hostname and CA do not need to match): openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 1 -nodes -subj "/CN=fake" && openssl s_server -key key.pem -cert cert.pem -accept 443 -HTTP.
4. Position for interception: Control the HTTP server the client initially contacts (e.g., via DNS poisoning, BGP hijack, or compromised upstream server), or intercept proxy traffic to inject the redirect response.
5. Trigger the vulnerable code path: The victim client, configured with a proxy and set_follow_location(true), makes a request that receives the 302 redirect. create_redirect_client() creates a new SSLClient with verification disabled.
6. Capture credentials and data: The client connects to the attacker's TLS endpoint, presents all loaded credentials (basic auth, bearer tokens, digest auth), and the attacker can read and modify the full request/response. The application receives no error (GitHub Advisory).

• Network: Unexpected TLS connections from cpp-httplib clients to unfamiliar or self-signed certificate endpoints following an HTTP redirect; TLS handshakes completing with certificates that fail standard validation (expired, self-signed, mismatched hostname).
• Network: Outbound HTTPS connections to hosts not in the original request target, particularly after traversing a proxy, indicating redirect-following behavior.
• Logs: Proxy access logs showing a client following a redirect from HTTP to HTTPS with a destination not matching expected application endpoints.
• Application Behavior: Successful HTTPS connections to endpoints that should fail certificate validation — no TLS errors logged despite connecting to hosts with invalid certificates.
• File System: Presence of cpp-httplib versions ≤ 0.37.1 (httplib.h) in application source trees or installed packages, identifiable via version string or file hash (GitHub Advisory).

Upgrade cpp-httplib to version 0.37.2 or later, which corrects the proxy branch of create_redirect_client() to copy the caller's certificate and hostname verification settings rather than unconditionally disabling them (GitHub Advisory). As an interim workaround if upgrading is not immediately possible, disable automatic redirect following (set_follow_location(false)) and handle redirects manually with full verification control, or implement certificate pinning at the application layer. Applications that do not use both a proxy and set_follow_location(true) simultaneously are not affected by this specific code path (Red Hat Bugzilla).

Red Hat tracked the vulnerability via their security response process (Bugzilla bug 2447488) and assigned it high priority and severity (Red Hat Bugzilla). The vulnerability was credited to researcher '0x3xploit' in the GitHub Security Advisory. German Linux news outlet Pro-Linux.de covered the issue, noting the improper signature/certificate validation in cpp-httplib (GitHub Advisory). No significant broader social media controversy or vendor disputes have been observed.