CVE-2026-8286: wrong STARTTLS connection reuse

How it was found

Finding F3 from Andrew Nesbit's report:

https://github.com/curl/curl/blob/455bebc2c7/lib/url.c#L1024-L1036 https://github.com/curl/curl/blob/455bebc2c7/lib/url.c#L825-L844

url_match_ssl_config() is gated on m->needle->scheme->flags & PROTOPT_SSL. For imap://, pop3://, smtp://, ftp://, ldap:// with CURLOPT_USE_SSL (STARTTLS), the scheme lacks PROTOPT_SSL, so Curl_ssl_conn_config_match is never called even though the connection runs TLS. url_match_ssl_use() at L833-838 lets a plain-scheme needle reuse an SSL-upgraded conn via PROTOPT_SSL_REUSE without ever reaching the config comparison; the req_tls check at L840 only fires when the existing conn is NOT ssl.

Impact

Impact: handle A connects imap://host with CURLOPT_USE_SSL=CURLUSESSL_ALL and CURLOPT_SSL_VERIFYPEER=0; on-path attacker MITMs the STARTTLS upgrade. Handle B connects imap://host with USE_SSL=ALL, VERIFYPEER=1, and a pinned key. B reuses A's unverified TLS session; B's verifypeer/pinning never run. (FTP's ftp_conns_match checks use_ssl level and ftp_ccc but not ssl_primary_config; IMAP/POP3/SMTP have no protocol-specific check at all.)

Same bug class as CVE-2022-27782 (TLS/SSH too-eager reuse) - that fix added Curl_ssl_conn_config_match but only behind a PROTOPT_SSL gate, missing the STARTTLS path. Verified by reading both functions and tracing the needle for imap:// + USE_SSL through url_match_ssl_use → returns TRUE at L838, then url_match_ssl_config → returns TRUE at L1028 without calling Curl_ssl_conn_config_match.