Live › vulnerability › CVE-2026-87866
Go to dashboardWhen curl is built with wolfSSL, a crafted certificate with a manipulated validity length field can make curl's pinned public key check match a key the TLS peer does not hold. An attacker in a position to present a certificate could get curl to accept a connection it should reject.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Only builds of curl linked against wolfSSL that rely on certificate public key pinning (CURLOPT_PINNEDPUBLICKEY or --pinnedpubkey) are described. Builds using OpenSSL, GnuTLS or other TLS backends, and users who do not pin public keys, are not described as affected.
No product ranges from the sources yet.
curl --version and look for wolfSSL in the SSL library lineUnknown from the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
When built with wolfSSL, curl can successfully validate a pinned public key hash against a key the TLS peer does not possess. During the TLS handshake, wolfSSL validates the connection, but curl's subsequent re-parsing of the same certificate - tricked by a manipulated validity length field - extracts and matches a different embedded key, incorrectly authorizing the pinned public key.
This page as .md · .json · in your agent: get_signal("CVE-2026-87866")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.