Listen to this Post
The vulnerability stems from a flaw in libcurl’s connection reuse logic when communicating with HTTP proxies that require authentication. When a connection to a proxy is established using the CONNECT method, it creates a tunnel, typically for HTTPS traffic. libcurl maintains a cache of these connections for performance reasons. The error occurs in the function responsible for matching an existing connection to a new request. Specifically, the matching logic compares the proxy’s type, host, and port but fails to compare the proxy username and password . Therefore, if a shared connection cache is used (via `CURLSH` and CURL_LOCK_DATA_CONNECT), a subsequent transfer that specifies different, or even invalid, proxy credentials can incorrectly reuse an existing CONNECT tunnel that was authenticated with a different set of valid credentials . This means a request intended to use “bad:bad” credentials can be sent over a tunnel originally set up with “good:good” credentials, effectively bypassing the proxy authentication policy for that second request . The proxy server only ever sees the first successful CONNECT request. This issue affects libcurl versions from 7.7 up to and including 8.18.0 and was fixed in version 8.19.0 .
dailycve form:
Platform: curl / libcurl
Version: 7.7 to 8.18.0
Vulnerability : Proxy credential reuse
Severity: Low (Medium context)
date: 2026-03-11
Prediction: Patch already available (8.19.0)
What Undercode Say:
Analytics
The vulnerability is present in code handling HTTP proxy CONNECT tunnels within the connection cache.
The root cause is in `url_match_proxy_use()` calling proxy_info_matches(), which omits a credential comparison .
Exploitation requires a shared connection cache (CURLSHOPT_SHARE with CURL_LOCK_DATA_CONNECT) .
The flaw allows a request with incorrect proxy credentials to succeed by reusing an authenticated tunnel .
The official patch is included in the curl 8.19.0 release .
The vulnerability was reported via HackerOne on March 4, 2026 .
Public disclosure and CVE assignment occurred on March 11, 2026 .
Exploit:
This is a conceptual demonstration of the flaw. It assumes a proxy (localhost:8080) requiring authentication and a target server. 1. Start a test proxy that logs credentials (e.g., using a simple Python script). 2. Compile a small C program using libcurl with a shared connection cache. Or, hypothetically, if the curl tool itself could share a cache this would work. The following curl commands demonstrate the intended failure without the cache. Transfer 1: Uses correct credentials, should succeed. curl -v -x http://proxy:8080 --proxy-user good:good https://example.com Transfer 2: Uses incorrect credentials. In a vulnerable, non-shared context, this fails with 407 Proxy Auth Required. curl -v -x http://proxy:8080 --proxy-user bad:bad https://example.com In a vulnerable shared cache context (like a daemon), the second command would succeed because libcurl would reuse the tunnel from the first command, never sending the "bad:bad" credentials to the proxy.
Protection from this CVE
Upgrade to curl/libcurl version 8.19.0 or later .
Apply the official patch if an immediate upgrade to 8.19.0 is not feasible .
As a workaround, avoid using a shared connection cache (CURLSH) in multi-tenant applications where different proxy credentials are used .
Disable HTTP proxy keep-alive or connection reuse if strict per-request authentication is required.
Impact
Bypass of HTTP proxy authentication policies .
In multi-tenant architectures or daemon services using a shared pool, a request can be executed under a more privileged proxy identity than intended .
Potential for unauthorized access to proxied resources that rely on the authenticated proxy user for access control decisions .
The primary risk is authentication and authorization bypass, not remote code execution .
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: nvd.nist.gov
Extra Source Hub:
Undercode
