libcurl's Negotiate authentication code has a logic flaw that can cause a request to reuse a connection authenticated for a
different user, exposing authenticated sessions to wrong-identity reuse and credential confusion — a vulnerability tracked as
CVE-2026-1965 that was disclosed and fixed by the curl project on March 11, 2026. (
curl.se)
Background
libcurl is one of the most widely embedded networking libraries in the open-source world and ships as the core component of the curl command-line tool. Many products and services — from desktop apps to cloud agents and embedded devices — rely on libcurl for HTTP(S) transfers and authentication flows. The library maintains a pool of reusable connections to reduce latency and resource consumption; under normal operation it must only reuse a connection when that connection's properties (host, TLS session, authentication state, credentials, proxy status, etc.) match the new request's needs.
The newly disclosed issue concerns the
HTTP Negotiate authentication mechanism (SPNEGO/GSSAPI), commonly used to negotiate Kerberos or NTLM tokens via the Negotiate "scheme" in HTTP. The curl project describes a logical error that allowed libcurl to select a connection already authenticated for a different set of credentials and reuse that connection for a new request that supplied a different user. The result: a request intended for one authenticated identity could be sent over a connection that had been authenticated for another identity, breaking the intended authentication isolation and potentially exposing confidential request/response data to the wrong authenticated session. (
curl.se)
This is not a theoretical change to a corner of the code — Negotiate can be
connection-scoped by some servers and proxies in practice, which clashes with HTTP's expectation that authentication is a per-request mechanism. The curl team explains that Negotiate behavior in the wild sometimes authenticates the
connection, not just a single request, and the reuse logic failed to account for that, allowing cross-user reuse. (
github.com)
What exactly is CVE-2026-1965?
The core failure mode
- Root cause: a logical error in libcurl's connection reuse matching code for HTTP(S) Negotiate authentication.
- Behavior: when presented with a new Negotiate-authenticated request using credentials A, libcurl might reuse a still-alive connection that was authenticated with credentials B if that connection otherwise matched the target server. Because the reused physical connection still carries the authenticated state from B, the new request ends up running under B's authenticated context instead of A's.
- Attack surface: any application that performs multiple Negotiate-authenticated HTTP(S) requests to the same host (or proxy) using different credentials while connection reuse is enabled. This includes both client applications and background services that multiplex requests across a shared connection pool.
Affected software and versions
The curl project has stated the flaw exists in curl/libcurl versions introduced when Negotiate support was added and persisted through recent releases. The project lists the affected range as
from curl 7.10.6 up to and including 8.18.0, and marks
curl 8.19.0 as the first fixed release. Multiple independent distributions (Ubuntu among them) mirrored that assessment and published patched packages. (
curl.se)
Severity and classification
The curl project assigns this issue a
Medium severity and classifies it under CWE-305 (Authentication Bypass by Primary Weakness). In practice, the impact depends entirely on how an application uses libcurl: some environments will see this as a low-risk logic bug, while in multi-tenant, credential-swapping, or delegated-auth systems it can create confusing authentication leakage that leads to data exposure or privilege mixing. (
curl.se)
Timeline and disclosure
The flaw was reported to the curl project on
February 4, 2026. After investigation and patch development, the project released the fix as part of curl/libcurl
8.19.0 on
March 11, 2026, concurrently publishing the advisory and associated patches. The fixes include logic changes to the connection matching code so that Negotiate-using connections are only reused when credentials match (or when reuse would be safe given the state).
Canonical (Ubuntu) and other distributors tracked the advisory and issued security notices and packaged updates for their supported releases; Ubuntu published a dedicated CVE entry and package status page on March 11, 2026. (
ubuntu.com)
Note: the Microsoft Security Response Center (MSRC) page for CVE-2026-1965 might appear unreachable or require JavaScript to render content when fetched by automated tools; attempts to load that specific MSRC URL from an automated context returned a page that shows the MSRC app shell rather than plain advisory content. Administrators relying solely on MSRC's web UI may need to use print-friendly exports, vendor advisories, or distribution security trackers to confirm platform-specific package availability. (
msrc.microsoft.com)
Technical analysis: why this bug matters
Connection pooling is a performance feature with security requirements
Connection reuse (pooling) is fundamental to modern HTTP performance. Re-establishing TCP and TLS handshakes for each request would be prohibitively expensive for many applications. To be safe, a connection pool must ensure that a connection's security-related attributes match the request's needs. That includes:
- server identity (host name / SNI)
- TLS session parameters and cipher suite
- proxy identity and proxy credentials
- authentication state and credentials used to obtain that state
If any of those differ between the original connection and the new request, reusing the connection is unsafe. The CVE-2026-1965 bug demonstrates how subtle protocol semantics (Negotiate being interpreted by some endpoints as “connection authenticated”) can break reuse logic if the library does not explicitly guard for credential equality. (
github.com)
Negotiate is special — sometimes connection-scoped
Negotiate is a meta-scheme that negotiates the underlying mechanism (Kerberos, NTLM, or others). In several server and proxy implementations, the outcome of a Negotiate exchange effectively binds authentication to the TCP connection (for example, a proxy that accepts a SPNEGO token for the connection). That behavior is contrary to a naive expectation that HTTP auth is request-scoped.
The curl fix addresses this mismatch by making the connection-matching logic aware of Negotiate state and verifying that either the matching connection was established with the same credentials or that Negotiate is not already in effect on the candidate connection. In short: do not reuse a Negotiate-authenticated connection for a request that supplies different credentials. (
github.com)
Practical exploitation scenarios
- Multi-user client: an application running on a shared host sends requests to the same backend with different user tokens (e.g., a management agent acting on behalf of different users). If the agent uses libcurl's connection pool and relies on Negotiate for authentication, a request for user B might go over an existing connection authenticated for user A, causing server-side access checks to run as user A.
- Proxy-mediated flows: if a proxy performs Negotiate for the client and connection reuse is allowed, multiple clients or logical sessions could share a single physical connection that was authenticated for another identity.
- Short-lived credential swaps: automated systems that temporarily escalate privileges or rotate credentials could inadvertently have their new requests run under the previous credential set if connections are reused without precise credential matching.
In each case, impact ranges from incorrect data being returned to sensitive data exposure if the response contains user-specific content. Because the vulnerability is not a remote code execution or buffer overflow, it is often overlooked in high-severity scans — yet it introduces logic-level authentication mistakes that can be exploited in multi-tenant contexts. (
curl.se)
Who must respond and how: guidance for admins, developers, and packagers
Immediate recommended actions (in order of preference)
- Upgrade to curl/libcurl 8.19.0 or later — this is the definitive fix from the curl project and is the recommended path for both applications that bundle libcurl and systems that rely on packaged libcurl libraries. Upstream distributes both the library and the curl CLI with the fix. (curl.se)
- Apply the patch and rebuild libcurl if upgrading is not immediately possible — the advisory includes the code changes and specific commits that address the issue. System integrators that manage their own builds should apply the commits and run their normal testing and QA cycles. The Git commits implementing the fix were merged into the mainline curl tree and are available as part of the fixset. (github.com)
- Temporary mitigations — if neither upgrading nor patching is feasible immediately, developers can configure libcurl to avoid connection reuse for Negotiate-authenticated requests by using available options:
- set CURLOPT_FRESH_CONNECT to force a new connection per transfer;
- limit connection reuse via CURLOPT_MAXCONNECTS;
- when using the multi API, configure CURLMOPT_MAX_HOST_CONNECTIONS appropriately.
These options increase connection overhead but block the unsafe reuse path until a proper fix can be installed. (curl.se)
For Linux distributors and package maintainers
- Distributors should prioritize backporting the curl 8.19.0 fix into stable branches where libcurl is bundled with other system packages. Ubuntu and other vendors have already published package updates and advisories; downstream maintainers should push those updates to affected release channels and notify users. The Ubuntu CVE entry and package statuses were updated on March 11, 2026. (ubuntu.com)
For application developers and integrators
- Audit code that:
- uses libcurl for Negotiate, SPNEGO, Kerberos, or NTLM flows;
- shares a long-lived libcurl handle or connection cache across different identity contexts;
- runs on multi-tenant services or agents that may authenticate on behalf of different identities.
- If your app uses libcurl in multi-user or long-running contexts, schedule an upgrade and add tests that verify credential separation: create tests that attempt authentication with one credential A, then issue a request with credential B and assert the server sees B, not A.
- Consider adjusting test harnesses to include connection reuse scenarios and proxy-mediated Negotiate flows.
Risk assessment and real-world impact
Not a memory corruption, but a logic-level auth failure
CVE-2026-1965 is not a memory safety or remote code execution issue; instead, it is a logic-level authentication isolation bug. Those bugs are easily underrepresented in automated criticality scoring because they require contextual knowledge about an application's use of credentials and connection patterns to determine impact. For some deployments (single-user clients, command-line tools invoked per authentication), the risk is negligible. For complex services that multiplex sessions or act as identity brokers, the risk is meaningful. (
curl.se)
Likelihood of exploitation
- The vulnerability can be exploited only where:
- Negotiate is in use and accepted by the server or proxy;
- libcurl connection reuse is enabled (default);
- multiple distinct credentials are used against the same server while connections remain alive.
- As a result, exploitation is unlikely in simple consumer scenarios but plausible in corporate networks, CI/CD agents, multi-user agents, or proxies that terminate authentication for multiple clients. Attackers would need to control or coerce the victim application into issuing requests with differing credentials in ways that create the reuse timing windows. (curl.se)
Long tail: embedded devices and OEM bundles
libcurl is often embedded into products with limited update mechanisms (IoT devices, appliances, closed-system agents). Those products may carry older libcurl versions in the vulnerable range. For vendors with long upgrade cycles, the bug introduces an ongoing risk until device firmware or software is refreshed. Distributors and OEMs should identify affected firmware images and plan coordinated updates. Ubuntu and other distros show which package versions were patched and which releases remained vulnerable as of the advisory date. (
ubuntu.com)
The fix: what changed in the code
The curl team implemented explicit checks in the connection matching logic to account for Negotiate-specific state. The new logic:
- adds flags to the connection match structure to track Negotiate desire and probe for existing Negotiate state;
- refuses to reuse a connection that is already in a Negotiate-authenticated state when the new request does not match the connection's credentials;
- ensures that Negotiate (and proxy-Negotiate) connections are only considered reusable when usernames/passwords (or proxy username/password) match the new request's supplied credentials.
This approach tightens reuse semantics in a way that preserves safety at the expense of fewer reuse opportunities when credentials differ. The explicit changes are committed in the curl repository and reflected in the official patch set. (
github.com)
Practical developer checklist
- Inventory: identify all applications that use libcurl (statically linked or dynamically linked).
- Version check: verify libcurl/curl versions on servers and endpoints; check whether versions fall within 7.10.6–8.18.0 inclusive.
- Prioritize: rank affected components by risk — multi-user agents, proxies, and server-side agents that authenticate on behalf of users should be high priority.
- Patch: upgrade to curl/libcurl 8.19.0 in all affected builds and distributions where feasible.
- Mitigate: where immediate upgrades are impossible, configure libcurl to disable reuse for Negotiate-authenticated requests or enforce fresh connections for credential-swapping operations.
- Test: add integration tests that validate per-request authentication isolation for Negotiate flows.
- Communicate: notify third-party vendors and OEMs if your product bundle includes libcurl, and request timelines for fixes or backports.
Broader implications for authentication design
This incident is a useful reminder that authentication semantics and protocol nuances can defeat optimistic performance optimizations like connection pooling. Libraries that implement reuse must be conservative when authentication state is involved. Design recommendations going forward:
- Libraries should expose explicit, easy-to-use controls for per-request reuse policies.
- Developers should prefer per-request explicitness when different credentials may be involved, even at a measurable performance cost.
- Security-sensitive environments should log and monitor reuse activity and authentication context switches to detect suspicious reuse or cross-tenant requests.
The curl fix demonstrates responsible engineering: rather than preserving reuse at all costs, the project tightened safety checks and provided clear mitigations for consumers. (
github.com)
How to verify you're safe
- Command-line users: run your system package manager and confirm the installed curl package equals or exceeds the patched version (packaged versions may vary; distributions have released backports for maintained branches).
- Developers bundling libcurl: inspect your bundled libcurl version and the underlying Git commit history; ensure the two commits noted in the advisory are present in your build. The advisory lists the specific patches and merges implemented in the mainline tree. (github.com)
- Automated scanners: update your inventory and scanning recipes to flag any libcurl instances in the affected version window; for packaging ecosystems, include the curl advisory as a matching criterion.
Closing assessment
CVE-2026-1965 is a classic example of how protocol details (Negotiate sometimes binding to a connection) can interact unexpectedly with performance optimizations (connection pools) to create authentication-safety issues. The flaw is not a memory corruption or a direct remote code execution vulnerability, but it introduces a logic error that can cause incorrect identity binding and potentially expose data or grant access under the wrong identity.
Fortunately, the curl project responded promptly: a coordinated fix was merged and published with curl 8.19.0 on March 11, 2026, and major distributions have already begun shipping updates. Administrators and developers should treat this as a high-priority correctness issue if their applications mix credentials with shared connection pools, and they should plan upgrades or mitigations accordingly. (
curl.se)
If you maintain software that uses libcurl for Negotiate/SPNEGO flows, plan an immediate action: inventory, patch, and test. Connection reuse is valuable — but not when it compromises authentication isolation.
Source: MSRC
Security Update Guide - Microsoft Security Response Center