curl and libcurl HTTP Proxy Connection Reuse Vulnerability

Vulnerability

A vulnerability exists in curl and libcurl versions 7.7 through 8.18.0, where the library improperly reuses an existing HTTP proxy connection that is doing CONNECT to a server. This occurs even when the new request involves different proxy credentials. The correct behavior would be to establish a new connection or use a separate one for the request with different credentials. This issue can lead to authentication bypass in scenarios where applications share a libcurl connection cache, allowing requests to be mistakenly authenticated through a reused proxy tunnel.

Impact

Exploiting this vulnerability can cause proxy authentication to be bypassed, particularly in applications that share a connection cache using CURLSHOPT_SHARE with CURL_LOCK_DATA_CONNECT. In such cases, a transfer with invalid proxy credentials can inadvertently use a previously authenticated CONNECT tunnel established with different credentials, potentially violating proxy authentication policies.

Reproduction

The vulnerability can be reproduced by performing two sequential transfers through an HTTP proxy that requires authentication. The first transfer should use valid proxy credentials, while the second transfer should use invalid credentials. When the connection sharing feature is enabled, the second transfer will succeed by reusing the authenticated connection, despite the credential mismatch. This behavior can also be replicated in a multi-client scenario, where a service manages a shared connection pool, allowing requests to bypass authentication enforcement.

Remediation

Users are advised to upgrade to curl and libcurl version 8.19.0, which addresses this vulnerability by restoring the proper proxy credential checks during connection reuse. Alternatively, the issue can be mitigated by avoiding the use of HTTP proxies with varying credentials.

Added: Mar 11, 2026, 11:19 AM
Updated: Mar 11, 2026, 11:19 AM

Vulnerability Rating

Custom Algorithm
spread
0.0
impact
1.3
exploitability
4.6
remediation
8.3
relevance
3.8
threat
6.4
urgency
2.9
incentive
0.0

Our algorithm analyzes dozens of metrics to generate these 8 key vulnerability categories, which are then combined to calculate the overall risk score.