CVE-2026-1965: Haxx Curl Auth Bypass Vulnerability

CVE-2026-1965 Overview

CVE-2026-1965 is an authentication bypass vulnerability in libcurl that affects how the library handles connection reuse when performing Negotiate-authenticated HTTP or HTTPS requests. Due to a logical error in the connection pooling mechanism, libcurl can incorrectly reuse an existing authenticated connection for requests that should use different credentials, potentially leading to unauthorized access or unintended actions performed under the wrong user context.

libcurl maintains a pool of recent connections to improve performance by reusing existing connections for subsequent requests. However, a flaw in the credential validation logic causes requests with different Negotiate authentication credentials to improperly share the same authenticated connection. This occurs because Negotiate authentication authenticates connections rather than individual requests, contrary to standard HTTP design principles.

Critical Impact

Applications using libcurl with Negotiate authentication may inadvertently perform operations using incorrect user credentials, potentially leading to unauthorized data access or modification across user contexts.

Affected Products

• Haxx curl (all versions with Negotiate authentication support)
• Applications and services built using libcurl with Negotiate/SPNEGO authentication
• Systems utilizing CURLOPT_HTTPAUTH with Negotiate authentication enabled

Discovery Timeline

• 2026-03-11 - CVE-2026-1965 published to NVD
• 2026-03-12 - Last updated in NVD database

Technical Details for CVE-2026-1965

Vulnerability Analysis

The vulnerability stems from improper connection reuse logic within libcurl's connection pooling mechanism. When an application performs a Negotiate-authenticated request to a server using one set of credentials (user1:password1), the connection is established and authenticated. If a subsequent request is made to the same server using different credentials (user2:password2) while the original connection remains alive, libcurl incorrectly reuses the already-authenticated connection instead of establishing a new one.

This behavior violates the expected authentication isolation between requests. The second request appears to complete successfully from the application's perspective, but it actually operates under the authentication context of the first user. This can result in unintended privilege usage, where operations meant to be performed as user2 are actually executed with user1's permissions and identity.

The root cause lies in how Negotiate (SPNEGO/Kerberos) authentication differs from other HTTP authentication mechanisms. While most HTTP authentication methods authenticate individual requests, Negotiate authenticates the underlying connection itself. Libcurl's connection reuse validation failed to account for this distinction when determining connection eligibility for reuse.

Root Cause

The vulnerability exists due to a logical error in libcurl's connection reuse criteria validation. Specifically, the code does not properly verify that the Negotiate authentication credentials match between the existing pooled connection and the new request. Since Negotiate authentication is connection-based rather than request-based, once a connection is authenticated, all subsequent requests on that connection inherit the original authentication context regardless of what credentials the application specifies for the new request.

Attack Vector

This vulnerability requires a network-based attack vector where an attacker can influence application behavior to trigger the connection reuse condition. The attack scenario involves:

1. An application authenticates to a server using Negotiate with legitimate user credentials
2. The same application subsequently attempts to authenticate to the same server with different user credentials
3. The second request unintentionally uses the first user's authenticated connection
4. Actions intended for the second user are performed under the first user's identity

The vulnerability is classified as CWE-305 (Authentication Bypass by Primary Weakness). While exploitation requires an attacker to have some level of access to influence application behavior, the impact is significant as it can lead to authorization bypass and unintended credential usage.

Detection Methods for CVE-2026-1965

Indicators of Compromise

• Unexpected user identity mismatches in application logs where operations are attributed to different users than expected
• Authentication audit logs showing operations performed by users who should not have had access at that time
• Connection reuse patterns in libcurl verbose logs showing Negotiate-authenticated connections being reused across different credential contexts
• Anomalous access patterns where user A's credentials appear to authorize actions typically restricted to user B

Detection Strategies

• Enable verbose logging in libcurl (CURLOPT_VERBOSE) to monitor connection reuse behavior during Negotiate authentication
• Implement application-level logging to track credential context for each HTTP operation and detect mismatches
• Monitor for authentication anomalies where user actions don't align with their expected permissions or session context
• Deploy network monitoring to identify connection reuse patterns between requests with different authentication headers

Monitoring Recommendations

• Audit all applications using libcurl with Negotiate authentication enabled via CURLOPT_HTTPAUTH
• Review application logs for any indication of cross-user credential confusion or unexpected authorization results
• Implement identity verification checks at the application layer to validate that response contexts match expected user credentials
• Establish baseline connection patterns for applications using Negotiate authentication to identify deviations

How to Mitigate CVE-2026-1965

Immediate Actions Required

• Audit all deployments using libcurl with Negotiate (SPNEGO/Kerberos) authentication for potential exposure
• Implement connection reuse restrictions using CURLOPT_FRESH_CONNECT to force new connections for each request
• Review application logic to ensure sensitive operations verify user context independently of transport authentication
• Consider isolating multi-user applications to use separate libcurl instances per user context

Patch Information

Haxx has released information regarding this vulnerability. Administrators should consult the official curl security advisory for the latest patching guidance and updated versions. Apply vendor patches as soon as they become available to address the underlying connection reuse logic flaw.

Workarounds

• Use CURLOPT_FRESH_CONNECT to disable connection reuse and force fresh connections for each request
• Set CURLOPT_MAXCONNECTS to 0 to prevent connection pooling when handling multiple user credentials
• For applications using the curl_multi API, configure CURLMOPT_MAX_HOST_CONNECTIONS to limit connection sharing
• Implement application-level credential verification to validate that responses match expected user contexts
• Consider alternative authentication mechanisms that are request-based rather than connection-based where feasible

# Configuration example for disabling connection reuse in curl applications
# Option 1: Force fresh connections (recommended for multi-user scenarios)
curl_easy_setopt(curl, CURLOPT_FRESH_CONNECT, 1L);

# Option 2: Disable connection pooling entirely
curl_easy_setopt(curl, CURLOPT_MAXCONNECTS, 0L);

# Option 3: For curl_multi API - limit host connections
curl_multi_setopt(multi, CURLMOPT_MAX_HOST_CONNECTIONS, 1L);