curl Connection Reuse and Token Leakage

Curl's SMB implementation contains a use-after-free vulnerability that causes denial of service when processing consecutive requests to the same host, as the library incorrectly dereferences freed memory on subsequent connections. Public exploit code exists for this vulnerability affecting Curl installations. An attacker can crash Curl-based applications or services by triggering multiple SMB requests, though remote code execution is not possible due to the nature of the memory corruption.

libcurl incorrectly reuses authenticated connections when processing Negotiate authentication requests, allowing an attacker with valid credentials to access resources authenticated under different user accounts. An authenticated attacker can exploit this connection pooling logic error to bypass authentication checks by reusing an existing connection that was authenticated with different credentials. This affects libcurl implementations using Negotiate authentication where multiple users access the same server.

curl's HTTP proxy connection reuse mechanism fails to validate credential changes, allowing an attacker to intercept or manipulate traffic by leveraging an existing proxy connection established with different authentication. This affects users whose applications reuse proxy connections across requests with varying credentials, enabling credential confusion attacks. Public exploit code exists for this vulnerability, though a patch is available.

OAuth2 bearer token leakage in curl and .NET occurs when HTTP redirects are followed to a second hostname that matches entries in the .netrc configuration file, allowing attackers to obtain valid authentication tokens for unintended hosts. Public exploit code exists for this vulnerability affecting curl and .NET applications that rely on OAuth2 authentication with automatic redirect handling. This medium-severity vulnerability (CVSS 5.3) requires network access but no user interaction, and patches are available from vendors.