CVE-2026-3784: 
cURL vulnerability analysis and mitigation

CVE-2026-3784 is a proxy authentication bypass vulnerability in curl titled "wrong proxy connection reuse with credentials." curl incorrectly reuses an existing HTTP proxy connection (established via CONNECT) for new requests that use different HTTP proxy credentials, instead of creating a separate connection. This affects curl versions 7.7 through 8.18.0 (inclusive), with the fix introduced in curl 8.19.0, released on March 11, 2026. The vulnerability was disclosed publicly on March 11, 2026, and carries a CVSS v3.1 base score of 6.5 (Medium) (curl Advisory, Feedly).

The root cause is classified as CWE-305 (Authentication Bypass by Primary Weakness): curl's connection reuse logic fails to account for differing proxy credentials when deciding whether to reuse an existing CONNECT tunnel through an HTTP proxy. When a shared connection cache is used (e.g., in multi-handle or daemon scenarios), a second request with different proxy credentials is incorrectly routed through an already-authenticated proxy tunnel established by a prior request. The vulnerability was introduced in commit a1d6ad26100bc493c7b04f1301b1634b7f5aa8b4 and fixed in commit 5f13a7645e565c5c1a06f3ef86e97afb856fb364. A proof-of-concept was submitted via HackerOne (report #3584903) by researcher Muhamad Arga Reksapati (nobcoder), demonstrating the bypass using a C daemon program (curl_wrap_daemon.c) and a Python proxy script (run_share_connect_poc.py) (curl Advisory, HackerOne PoC).

Successful exploitation allows an unauthenticated attacker (or a lower-privileged user sharing a connection cache) to bypass HTTP proxy authentication by having their requests tunneled through a proxy connection authenticated with another user's credentials. This results in unauthorized access to resources behind the proxy that the attacker would not normally be permitted to reach, with low confidentiality and low integrity impact. Availability is not affected. The impact is most significant in multi-tenant or shared-process environments where curl's connection cache is shared across requests with different proxy credentials (curl Advisory, Feedly).

1. Reconnaissance: Identify environments where curl (versions 7.7–8.18.0) is used with a shared connection cache (e.g., multi-handle applications, daemon processes) and HTTP proxy authentication is enforced as an access control boundary.
2. Setup: Configure a local HTTP proxy that requires authentication and can observe or intercept CONNECT tunnel reuse behavior.
3. Trigger first connection: Issue a curl request through the HTTP proxy using valid credentials (e.g., user1:pass1), establishing an authenticated CONNECT tunnel to a target server.
4. Issue second request with different credentials: Using the same shared connection cache, issue a new curl request to the same proxy/target combination but with different proxy credentials (e.g., user2:pass2).
5. Observe bypass: curl incorrectly reuses the existing authenticated tunnel from step 3 instead of creating a new connection, effectively bypassing proxy authentication for the second request and granting access to resources the second credential set would not normally reach.
6. Access unauthorized resources: The attacker's request is forwarded through the already-authenticated proxy tunnel, allowing access to backend resources protected by proxy-based access controls (HackerOne PoC, curl Advisory).

• Network: Unexpected or anomalous CONNECT tunnel reuse observed in HTTP proxy logs — a single established tunnel serving requests from multiple distinct proxy credential identities without re-authentication.
• Logs: HTTP proxy access logs showing requests authenticated under one credential set (user1) immediately followed by requests from a different credential set (user2) on the same TCP connection/tunnel without a new CONNECT handshake.
• Application: curl-based applications or daemons exhibiting unexpected cross-user resource access when a shared CURLSH handle or multi-handle is in use with differing CURLOPT_PROXYUSERPWD values across easy handles.

Upgrade curl and libcurl to version 8.19.0 or later, which contains the fix (commit 5f13a7645e565c5c1a06f3ef86e97afb856fb364). If immediate upgrade is not possible, apply the upstream patch and rebuild libcurl. As a configuration-based workaround, avoid using HTTP proxies with alternating credentials in the same curl session or shared connection cache. Linux distributions including Ubuntu (USN-8084-1, USN-8099-1), SUSE/openSUSE, Fedora, and Slackware have released updated packages (curl Advisory, Openwall Advisory).

Daniel Stenberg (curl project lead) announced the release of curl 8.19.0 alongside the advisory on his blog, coordinating disclosure with the oss-security mailing list and downstream distributors via distros@openwall. The curl project rated the severity as "Low," noting it is not considered a C language mistake. Red Hat, Microsoft, Ubuntu, SUSE, Fedora, and other major Linux distributions promptly issued security advisories and updated packages. Community discussion on Bluesky and security aggregators noted the broad version range affected (dating back to curl 7.7) and the availability of a public PoC (Daniel Stenberg Blog, Openwall Advisory).