CVE-2026-80230: OpenSSL pinning bypass
When CURLOPTPINNEDPUBLICKEY is configured alongside options that disable standard peer verification (CURLOPTSSLVERIFYPEER = 0 and CURLOPTSSLVERIFYHOST = 0), libcurl fails to enforce public key pinning on connections established without a presented server certificate. Bypassing the pinning check under these disabled-verification conditions allows unauthenticated connections to succeed when they should be rejected.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Do not set CURLOPT_SSL_VERIFYHOST = 0 when using CURLOPT_PINNEDPUBLICKEY; ensure host verification remains enabled so libcurl enforces the pinning check.
libcurl (CURLOPT_PINNEDPUBLICKEY usage) CURLOPT_SSL_VERIFYHOST = not 0 - Configuration
Do not set CURLOPT_SSL_VERIFYPEER = 0 when using CURLOPT_PINNEDPUBLICKEY; keep standard peer verification enabled to prevent unauthenticated connections from succeeding alongside pinning.
libcurl (CURLOPT_PINNEDPUBLICKEY usage) CURLOPT_SSL_VERIFYPEER = not 0
Event History
Frequently Asked Questions
Which deployments are affected?
Deployments are affected when libcurl uses CURLOPT_PINNEDPUBLICKEY while both CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST are set to 0. The issue applies to connections where the server does not present a certificate.
What configuration change can reduce exposure before an update is available?
Do not disable both standard peer and host verification options when public-key pinning is configured. Requiring normal peer and host verification prevents the described disabled-verification condition.
How can I determine whether an application may be exposed?
Review libcurl option handling for CURLOPT_PINNEDPUBLICKEY combined with CURLOPT_SSL_VERIFYPEER = 0 and CURLOPT_SSL_VERIFYHOST = 0. Applications using that combination may accept an unauthenticated connection without a presented server certificate.