CVE-2026-3784: wrong proxy connection reuse with credentials

Summary libcurl may reuse an existing HTTP proxy CONNECT tunnel without matching proxy credentials when selecting a reusable connection. In lib/url.c, url_match_proxy_use() calls proxy_info_matches() (lib/url.c:930-935 → lib/url.c:589-595), and that matcher compares proxy type, host, and port but does not compare proxy username or password. When a shared connection cache is used (CURLSH + CURL_LOCK_DATA_CONNECT), a transfer using different proxy credentials can reuse a previously authenticated tunnel. In my reproduction the proxy receives only one CONNECT request with good:good, while a second transfer configured with bad:bad succeeds through the existing tunnel without issuing a new CONNECT. This was reproduced both with sequential libcurl transfers and with a wrapper/daemon model where multiple clients submit jobs to a process holding the shared connection cache. Control tests show the issue does not occur when connections are not shared (noshare) or when the destination host differs. Affected version Reproduced on: curl 8.18.0 (x86_64-pc-linux-gnu) libcurl/8.18.0 OpenSSL/3.5.5 zlib/1.3.1 brotli/1.2.0 zstd/1.5.7 libidn2/2.3.8 libpsl/0.21.2 libssh2/1.11.1 nghttp2/1.64.0 ngtcp2/1.16.0 nghttp3/1.12.0 librtmp/2.3 mit-krb5/1.22.1 OpenLDAP/2.6.10 Release information: Release-Date: 2026-01-07 security patched: 8.18.0-2 Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd Steps To Reproduce 1. Build the PoC program using libcurl. 2. Start the local proxy reproducer script. python3 /tmp/run_share_connect_poc.py 3. The script performs two transfers via a proxy. Transfer 1: proxy credentials: good:good Transfer 2: proxy credentials: bad:bad MODE noshare - first request succeeds - second request fails with proxy authentication error - proxy observes two CONNECT requests MODE share - both requests succeed - proxy observes only one CONNECT request - CONNECT uses good:good - second request (bad:bad) is sent through existing tunnel Run the wrapper daemon scenario (curl_wrap_daemon.c) to simulate a service using a shared connection pool. The second client using bad:bad credentials still succeeds while the proxy sees only the original CONNECT. ## Impact When applications share a libcurl connection cache using CURLSHOPT_SHARE with CURL_LOCK_DATA_CONNECT, proxy authentication contexts can be mixed across requests. A transfer specifying invalid proxy credentials may reuse a previously authenticated CONNECT tunnel established with different credentials. In multi-tenant architectures or wrapper/daemon services that reuse a shared connection pool, this can allow requests to bypass proxy authentication policy enforcement.