libcurl CVE-2026-8932: mTLS connection reuse ignored client key differences

A low-severity vulnerability in libcurl, tracked as CVE-2026-8932, allowed a TLS connection authenticated with one client certificate to be reused for a request configured with a different private key. According to a write-up on dev.to, libcurl versions 7.7 through 8.20.0 are affected, and the fix shipped in curl 8.21.0 on 24 June 2026. The curl command-line tool itself is not affected.

What went wrong

libcurl holds open TLS connections after a transfer finishes and recycles them when a later transfer appears to use the same settings. The vulnerability sits in the logic that decides what counts as the same. TLS configuration is split across two internal structs: ssl_primary_config, the one actually consulted by the reuse check in match_ssl_primary_config() and by the TLS session-cache key, and the larger ssl_config_data, which holds the remaining options. Five fields that configure how a client certificate is unlocked — cert_type, key, key_type, key_passwd and key_blob, exposed as SSLCERTTYPE, SSLKEY, SSLKEYTYPE, KEYPASSWD and SSLKEYBLOB — lived in ssl_config_data, outside the comparison. The certificate path itself was compared, but the fields describing which private key opens that certificate were not. If two handles differed in nothing but those five options, the check still reported a match, and they could end up sharing a single authenticated connection.

The session cache had a parallel weakness. Its cache key appended a fixed ':CCERT' marker to indicate that a client certificate was used, without recording which one, so sessions established with different certificates could collide in the cache.

How the bypass plays out

The practical exposure falls on applications that share a connection pool across multiple easy handles, either through a CURLSH share handle or a multi handle. The dev.to article points to the typical case of a backend proxy or API gateway where many users are each authenticated over mTLS with their own private key. One handle connects with a certificate and key, completes the handshake, and the pool records the connection as authenticated for that user. A second handle then sends a request using the same certificate file but a different key. Because the reuse check only verifies the certificate path, the second handle receives the existing connection with no new handshake, and the backend processes the request as the first user. The curl team classified the issue as CWE-305, an authentication bypass, describing it as a flaw of logic rather than memory safety and citing CVE-2022-27782 as a similar earlier case. Joshua Rogers of Aisle Research reported it.

The fix

Commit 7541ae5 promotes the five fields from ssl_config_data into ssl_primary_config, so the reuse comparison now covers certificate type, key, key type, key password and key blob. The password is compared with Curl_timestrcmp(), a routine designed to resist timing attacks. Because the fields moved, references had to be updated in 19 backend files, among them openssl.c, gtls.c, mbedtls.c, rustls.c, schannel.c and wolfssl.c, with expressions such as ssl_config->key becoming ssl_config->primary.key. On the session-cache side, the fixed ':CCERT' marker was replaced with the actual client certificate value, so sessions tied to different certificates no longer share an entry. The clone and free routines gained handling for the relocated fields, and two new test cases, 3303 and 3304, validate the behaviour.

Who needs to act

dev.to reports the severity as low, with no CVSS 3.1 score published by cve.org or Red Hat at the time of writing and curl's own rating also low. The bug traces back to a change around curl 7.7, roughly 2010, meaning it sat in the code for close to sixteen years. The command-line tool is unaffected because every invocation is a fresh process with its own pool. Exposure is confined to long-running applications that share connections across handles while varying client-certificate key material; for those, the remediation is an upgrade to 8.21.0.

Why it matters

This is a case where a correctness bug quietly becomes a security bug. No memory was misused and no data was corrupted; the library simply asked the wrong question, checking whether two handles named the same certificate file rather than whether they represented the same identity, before recycling a connection. The broader lesson is that connection pooling and mutual TLS interact badly unless every credential that shapes the handshake is part of the pool key. Teams operating multi-tenant proxies or API gateways that multiplex many client identities through libcurl should weigh the upgrade more seriously than the low severity rating suggests, since a request accepted under the wrong identity can be worse than a request that fails. The sixteen-year lifetime of the bug is also a reminder that widely deployed libraries benefit from periodic re-examination of assumptions written a decade or more ago.