CVE-2026-80230 in libcurl
Summary
by MITRE • 09/06/2026
When `CURLOPT_PINNEDPUBLICKEY` is configured alongside options that disable standard peer verification (`CURLOPT_SSL_VERIFYPEER = 0` and `CURLOPT_SSL_VERIFYHOST = 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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/06/2026
The vulnerability described involves a critical logic flaw in how libcurl handles Public Key Pinning, specifically through the CURLOPT_PINNEDPUBLICKEY option, when standard SSL/TLS verification mechanisms are explicitly disabled by the application developer. In typical secure configurations, public key pinning serves as an additional layer of trust assurance, ensuring that the connection is made to a server possessing a specific cryptographic identity rather than relying solely on traditional Certificate Authority chains. However, this security control relies heavily on the presence and validation of a presented X509 certificate from the remote peer. When an application configures libcurl with CURLOPT_SSL_VERIFYPEER set to zero and CURLOPT_SSL_VERIFYHOST also set to zero, it instructs the library to bypass standard hostname and certificate chain verification entirely. This configuration is often used in development environments or for specific internal use cases where trust boundaries are managed differently, but it introduces a significant security regression when combined with pinning expectations.
The core technical flaw lies in the conditional logic within libcurl's SSL backend implementation. The library checks whether standard peer verification is enabled before proceeding to validate the pinned public key against the certificate presented by the server. If both CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST are disabled, the code path that performs the pinning validation is effectively skipped or bypassed because the prerequisite condition for a valid certificate presentation is not met. Consequently, if the remote server fails to present any certificate at all during the TLS handshake, libcurl does not trigger an error related to public key mismatch. Instead, it allows the connection to proceed as successful despite the absence of the expected cryptographic proof. This behavior contradicts the intended security model where pinning should act as a strict gatekeeper regardless of other verification settings, or at least fail securely when no certificate is available for comparison.
From an operational impact perspective, this flaw enables unauthenticated connections that should be rejected to succeed without raising any alarms within the application layer. An attacker performing a man-in-the-middle attack could potentially intercept traffic by presenting no certificate or a self-signed certificate that does not match the pinned key, and libcurl would accept it due to the disabled verification flags. This undermines the primary purpose of public key pinning, which is to prevent unauthorized intermediaries from injecting malicious content or exfiltrating sensitive data. The risk is particularly acute in scenarios where developers disable standard SSL verification for convenience but still rely on pinning as their sole method of authenticating the server's identity. In such cases, the application believes it has established a secure channel based on the pinned key, while in reality, no cryptographic authentication has occurred, leaving the communication vulnerable to interception and manipulation by any network adversary with sufficient positioning capabilities.
This vulnerability aligns closely with CWE-295 Improper Certificate Validation, as the system fails to properly validate the authenticity of the peer's identity under specific configuration states. It also relates to CWE-613 Insufficient Session Expiration, in a broader sense of session integrity, but more accurately fits CWE-749 Exposure of Security Feature Under Unusual or Unexpected Conditions, where the security feature (pinning) is exposed due to an unusual combination of disabled verification flags. In terms of MITRE ATT&CK techniques, this flaw facilitates Network Sniffing and Man-in-the-Middle attacks by allowing adversaries to bypass authentication controls that were intended to be robust. The lack of enforcement means that even if the application intends to enforce strict identity checks via pinning, the configuration error renders those checks inert against attackers who can control the TLS handshake parameters or exploit the disabled verification state.
To mitigate this vulnerability, developers must ensure that public key pinning is not used as a substitute for standard SSL/TLS certificate validation unless explicitly designed to handle cases where no certificate is presented. If CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST are set to zero, it indicates an intent to skip all server authentication checks; therefore, relying on CURLOPT_PINNEDPUBLICKEY in this context provides a false sense of security. The recommended remediation strategy involves either re-enabling standard SSL verification by setting these options to one, thereby allowing libcurl to properly validate the certificate chain and subsequently check the pinned key against it, or implementing custom callback logic that explicitly handles the case where no certificate is presented during the handshake. In such a scenario, the application should programmatically reject the connection if CURLOPT_PINNEDPUBLICKEY is configured but no X509 certificate is available for comparison. Additionally, security audits of libcurl integration code should verify that pinning configurations are not paired with disabled verification flags to prevent this specific bypass vector from being exploited in production environments.