CVE-2026-1965: 
cURL vulnerability analysis and mitigation

CVE-2026-1965 is an authentication bypass vulnerability in libcurl, described as "bad reuse of HTTP Negotiate connection." Due to a logical error in libcurl's connection reuse logic, an application using Negotiate authentication may have a subsequent request (with different credentials) incorrectly reuse an existing authenticated connection, causing it to execute under the wrong user's authentication context. All versions of curl/libcurl from 7.10.6 through 8.18.0 are affected; versions prior to 7.10.6 and 8.19.0 or later are not affected. The vulnerability was disclosed on March 11, 2026, and carries a CVSS v3.1 base score of 6.5 (Medium) (curl.se Advisory, Feedly).

The root cause is a logical error in libcurl's connection pool reuse logic, classified as CWE-305 (Authentication Bypass by Primary Weakness) and CWE-303 (Incorrect Implementation of Authentication Algorithm) (curl.se Advisory, Red Hat Bugzilla). The flaw arises because HTTP Negotiate (Kerberos/SPNEGO) authenticates at the connection level rather than the request level — once a connection is authenticated, libcurl incorrectly treats it as valid for any subsequent request to the same server, even if different credentials are supplied via CURLOPT_HTTPAUTH. An attacker or application scenario where user2:password2 makes a request to the same server while a connection authenticated as user1:password1 is still alive will result in the second request being sent over the first user's authenticated connection. This flaw is analogous to CVE-2014-0015, which affected NTLM authentication. The vulnerability was introduced with commit e56ae1426c and fixed in commits 34fa034d9a390c4bd6 and f1a39f221d57354990 (curl.se Advisory).

Successful exploitation allows a low-privileged network attacker to bypass authentication controls and perform actions under a different authenticated user's context, resulting in a high integrity impact (CVSS integrity: High) with no direct confidentiality or availability impact. In practice, an attacker could access or modify resources that should be restricted to another user, with the scope of impact depending on the permissions of the hijacked authenticated session. This is particularly relevant in multi-tenant or multi-user applications that share a libcurl connection pool and use Negotiate authentication against the same server (curl.se Advisory, Feedly).

1. Identify a vulnerable application: Find an application using libcurl versions 7.10.6–8.18.0 that makes Negotiate-authenticated HTTP/HTTPS requests to a server, and that allows multiple users to share the same libcurl connection pool (e.g., a multi-user server-side application).
2. Trigger an initial authenticated connection: Cause the application to make a Negotiate-authenticated request as user1 to the target server, establishing an authenticated connection in libcurl's connection pool.
3. Issue a second request with different credentials: While the user1 connection remains alive in the pool, trigger the application to make another Negotiate-authenticated request to the same server using user2:password2 credentials.
4. Connection reuse occurs: Due to the logical error in libcurl's connection reuse logic, the second request reuses the existing user1 connection. Since Negotiate authentication is already complete on that connection, libcurl skips re-authentication and sends the user2 request over the user1 session.
5. Unauthorized access achieved: The server processes the request as user1, granting user2's request access to resources or actions permitted only to user1, effectively bypassing authentication controls (curl.se Advisory, Red Hat Bugzilla).

• Logs: Server-side access logs showing requests attributed to one user account performing actions inconsistent with that user's normal behavior or permissions, particularly when multiple users share the same source IP or application backend.
• Application Logs: libcurl debug logs (enabled via CURLOPT_VERBOSE) showing connection reuse events where the authenticated user identity does not match the requested credentials for Negotiate-authenticated sessions.
• Network: HTTP/HTTPS traffic to a server using Negotiate (Kerberos/SPNEGO) authentication where the same TCP connection is reused across requests that should have different authentication contexts (observable via packet capture showing a single TLS session with multiple HTTP requests under different user contexts).
• Behavioral: Unexpected access to resources by user accounts that should not have permission, particularly in applications using libcurl with CURLOPT_HTTPAUTH set to include Negotiate (curl.se Advisory).

The primary remediation is to upgrade curl/libcurl to version 8.19.0 or later, which ensures that Negotiate-authenticated connections are not reused unless credentials match (curl.se Advisory). Patches are available for major Linux distributions including Ubuntu (USN-8084-1, USN-8099-1), SUSE/openSUSE, Fedora, and Slackware. For applications that cannot immediately patch, the following libcurl options can be used to disable connection reuse as a temporary workaround: CURLOPT_FRESH_CONNECT (disable reuse per request), CURLOPT_MAXCONNECTS (limit pool size to 0), or CURLMOPT_MAX_HOST_CONNECTIONS (when using the curl_multi API). Note that these workarounds reduce performance and should only be used as interim measures pending patch deployment (Red Hat Bugzilla).

The curl project maintainer Daniel Stenberg announced the fix as part of the curl 8.19.0 release blog post on March 11, 2026 (Daniel Stenberg Blog). The vulnerability was disclosed via the oss-security mailing list and received coverage from Linux security news outlets and distribution security teams across Ubuntu, SUSE, openSUSE, Fedora, and Slackware. Community discussion on platforms like Bluesky and Reddit (r/opnsense) noted the vulnerability in the context of security audits flagging affected curl versions. The curl advisory notes a similarity to the older CVE-2014-0015 (NTLM connection reuse), which provided historical context for the security community (curl.se Advisory, oss-sec).