CVE-2026-80230: 
cURL vulnerability analysis and mitigation

CVE-2026-80230 is an OpenSSL pinning bypass vulnerability in curl and libcurl that allows unauthenticated connections to succeed when public key pinning should have rejected them. It affects curl versions 7.45.0 through 8.21.0 (inclusive) and was introduced in commit 8363656cb4e0c60a11d8531. The vulnerability was reported on August 24, 2026, and publicly disclosed on September 2, 2026, coordinated with the release of curl 8.22.0. It carries a severity rating of Low and is classified under CWE-295 (Improper Certificate Validation) (curl Advisory).

The root cause (CWE-295) lies in how libcurl handles the CURLOPT_PINNEDPUBLICKEY option when peer verification is explicitly disabled via CURLOPT_SSL_VERIFYPEER = 0 and CURLOPT_SSL_VERIFYHOST = 0. Under these conditions, libcurl fails to enforce public key pinning on connections where the server presents no certificate, allowing the pinning check to be silently bypassed. The flaw is specific to builds of libcurl using OpenSSL or its forks (BoringSSL, AWS-LC, LibreSSL, QuicTLS, etc.), and exploitation requires the user to have already weakened security by enabling a non-default OpenSSL configuration. The fix was applied in commit 5267ed859d545534d0c21 and shipped in curl 8.22.0 (curl Advisory, oss-sec).

Successful exploitation allows an attacker to establish an unauthenticated TLS connection to a libcurl client that has configured public key pinning, effectively defeating the pinning protection intended to prevent man-in-the-middle (MitM) attacks. This could expose sensitive data transmitted over the connection to interception or tampering. However, exploitation requires the target application to have already disabled standard peer verification (CURLOPT_SSL_VERIFYPEER = 0 and CURLOPT_SSL_VERIFYHOST = 0), significantly limiting the real-world attack surface (curl Advisory).

No public exploit code or in-the-wild exploitation has been reported for CVE-2026-80230 as of the disclosure date. The CVE status was listed as "Reserved" at the time of Feedly ingestion, and the curl project rates the severity as Low, reflecting the constrained exploitation preconditions. The vulnerability was discovered by Stanislav Fort of Aisle Research, which reportedly identified six curl CVEs in this research cycle (Aisle Blog, curl Advisory). No CISA KEV listing or threat actor attribution has been observed.

1. Identify a vulnerable target: Find an application using libcurl 7.45.0–8.21.0 (built with OpenSSL or a fork) that has configured CURLOPT_PINNEDPUBLICKEY but also explicitly sets CURLOPT_SSL_VERIFYPEER = 0 and CURLOPT_SSL_VERIFYHOST = 0.
2. Position for MitM: Place yourself in a network position between the libcurl client and its intended server (e.g., via ARP spoofing, DNS hijacking, or rogue Wi-Fi access point).
3. Intercept the TLS handshake: Respond to the client's TLS connection attempt without presenting a valid server certificate, exploiting the condition where libcurl skips the pinning check when no certificate is presented.
4. Establish unauthenticated connection: Because libcurl fails to enforce the pinned public key check under these disabled-verification conditions, the connection proceeds, allowing the attacker to intercept or manipulate the traffic (curl Advisory).

• Network: Unexpected TLS connections completing without a valid server certificate presented; TLS handshakes to known endpoints that terminate with unusual cipher negotiation or missing certificate chains.
• Logs: Application logs showing successful connections to endpoints where pinning failures would normally be expected; absence of certificate validation error messages in libcurl debug output (CURLOPT_VERBOSE) despite misconfigured peer verification settings.
• Process/Configuration: Applications invoking libcurl with both CURLOPT_PINNEDPUBLICKEY set and CURLOPT_SSL_VERIFYPEER/CURLOPT_SSL_VERIFYHOST set to 0 simultaneously — this combination is the prerequisite for exploitation (curl Advisory).

The primary remediation is to upgrade curl and libcurl to version 8.22.0, released September 2, 2026, which contains the fix in commit 5267ed859d545534d0c21. Alternatively, apply the patch to your current version and rebuild. As a configuration-level workaround, avoid using CURLOPT_PINNEDPUBLICKEY in combination with CURLOPT_SSL_VERIFYPEER = 0 and CURLOPT_SSL_VERIFYHOST = 0 — enabling standard peer verification eliminates the vulnerable code path entirely (curl Advisory).

The vulnerability was discovered by Stanislav Fort of Aisle Research, which published a blog post noting it had identified six curl CVEs — drawing contrast with AI tools from OpenAI and Anthropic that reportedly found zero (Aisle Blog). Daniel Stenberg, curl's lead maintainer, authored the patch and coordinated the disclosure, noting in the advisory that the bug is not considered a C language mistake and that exploitation requires non-default OpenSSL configurations. The curl project's own characterization of the severity as "Low" reflects the constrained real-world impact (curl Advisory, Daniel's Blog).