CVE-2026-8932: incomplete mTLS config matching in conn reuse

Hi all,

This report (and my multiple subsequent ones) may come as a surprise, as I was assured that curl now had zero vulnerabilities in it.

Nonetheless, I think the CVE-2022-27782 fix ("TLS and SSH connection too eager reuse", commit f18af4f874 2022-05-09, "tls: check more TLS details for connection reuse") was incomplete: it moved a batch of SSL knobs into ssl_primary_config so conn-reuse would compare them, but left the credential-half of the mTLS pair behind in ssl_config_data. Two easy handles sharing a CURLSH/CURLM pool can reuse each other's authenticated TLS connection whenever they differ only on SSLKEY, SSLKEY_BLOB, KEYPASSWD, SSLKEYTYPE, or SSLCERTTYPE. The second handle silently inherits the first's authenticated identity to the server.

The conn-reuse gate is match_ssl_primary_config at lib/vtls/vtls.c:194-225, called via Curl_ssl_conn_config_match (lib/vtls/vtls.c:227-240) from url_match_ssl_config in lib/url.c:991-1003. Its argument type is struct ssl_primary_config * — it literally cannot see anything outside primary. The struct split is in lib/urldata.h:143-168 (primary, compared) vs lib/urldata.h:170-193 (ssl_config_data, not compared). connectdata (lib/urldata.h:389-392) only carries the primary copy into the pool, so once a conn is parked the full ssl_config_data it was born from is gone.

A similar gap exists in the TLS session cache. Curl_ssl_peer_key_make (lib/vtls/vtls_scache.c:137-294) builds the scache lookup key from primary only, and for the client cert it just adds a literal :CCERT marker — same five bytes regardless of which key/cert is set: