CVE-2026-80230: OpenSSL pinning bypass
Last updated 16 September 2026
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/curlto a version that resolves this vulnerability.Fixed in 8.22.0-1Fixed in 8.23.0~rc1-2 - Configuration
Do not disable standard peer and host verification when CURLOPT_PINNEDPUBLICKEY is configured; avoid setting CURLOPT_SSL_VERIFYPEER = 0 and CURLOPT_SSL_VERIFYHOST = 0.
libcurl CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST = 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.