curl CVE-2026-87866

Exploitation requires three conjunctive conditions: (1) libcurl must be built with the wolfSSL TLS backend - builds using OpenSSL, GnuTLS, Schannel, or other backends are unaffected; (2) the calling application must have explicitly enabled public-key pinning via CURLOPT_PINNEDPUBLICKEY (or the --pinnedpubkey tool option), which is a non-default, opt-in hardening feature; and (3) the attacker must already hold a man-in-the-middle position capable of presenting an alternate server certificate. The flaw does not create interception capability on its own - it only nullifies the pinning layer meant to detect such interception. Limiting factors that reduce real-world risk: the wolfSSL-specific build requirement, the explicit pinning configuration requirement, and the prerequisite MITM network position. Affected versions run up to 8.22.0 and are fixed in curl 8.23.0.

No CVSS vector, EPSS score, KEV listing, or POC is provided for CVE-2026-87866, so quantitative exploitation signals are entirely absent and cannot be cross-referenced. The authoritative source - the curl security team - rates this vulnerability LOW severity, which is the strongest available signal and aligns with the nature of the flaw: a bypass of the optional CURLOPT_PINNEDPUBLICKEY public-key pinning defense in libcurl builds using the wolfSSL TLS backend. Pinning is a defense-in-depth control, so bypassing it does not by itself grant access - an attacker must independently be positioned to present a substitute server certificate (a man-in-the-middle capability), meaning this lowers a hardening layer rather than opening a direct exploit path. This is NOT a high-priority, mass-exploitable issue: it is low severity, requires a non-default feature (pinning) to be configured, requires a specific TLS backend (wolfSSL), and requires an attacker already in a privileged network position. It warrants routine patching to curl 8.23.0, especially in embedded/IoT fleets that both use wolfSSL and rely on pinning, but it is not an emergency. Note that curl and libcurl are described by the vendor as being in over twenty billion installations, so even a low-severity flaw has an unusually large installed base - however, the wolfSSL-backed-plus-pinning configuration is a minority of that base.

An attacker able to intercept TLS traffic (e.g., on a shared or hostile network) presents a server certificate with a public key different from the one the client application pinned via CURLOPT_PINNEDPUBLICKEY. Because the wolfSSL-backed libcurl build mishandles the pin comparison, the connection that should have been rejected is instead accepted, defeating the pinning protection and allowing interception or tampering of the transfer. No public exploit identified at time of analysis.