If your application uses curl or libcurl with HTTP Negotiate/SPNEGO authentication against the same host using multiple credentials or long-lived reusable connections, upgrade to curl/libcurl 8.19.0 now; CVE-2026-1965 was disclosed on March 11, 2026, and affects versions 7.10.6 through 8.18.0. If you cannot patch immediately, block the risky reuse path with
CVE-2026-1965 is not the kind of curl flaw most administrators can safely wave away as a theoretical parser bug in some forgotten protocol corner. It sits in the place where libcurl is most often treated as boring infrastructure: connection reuse. The failure mode is simple enough to be operationally alarming: a later request can reuse a connection authenticated for a different user.
That matters because HTTP Negotiate, commonly associated with SPNEGO and Kerberos-style enterprise authentication, is often used precisely where identity boundaries matter. In a domain environment, an internal service may trust that the authenticated connection represents the current user or service account. If libcurl gets that identity wrong, the application can end up sending a request under the wrong authenticated session.
The curl project’s own recommendation order starts with upgrading to curl and libcurl 8.19.0. That should also be the default WindowsForum answer. If you own the application, rebuild or relink against the fixed libcurl; if you consume curl through a distribution, vendor appliance, SDK, package manager, or embedded runtime, track that supply chain until the fixed version actually lands in your deployed stack.
Blocking Negotiate reuse is a useful emergency brake. It is not the same thing as repairing the steering.
CVE-2026-1965 turns that optimization into a security boundary problem. The vulnerable versions can decide that an existing connection to the same server is reusable even when that connection was authenticated using different credentials. In the specific scenario described by the curl advisory, an application uses Negotiate authentication as one user, then performs another Negotiate-authenticated operation to the same server as another user while the previous connection is still alive.
The second request may believe it is operating with the second user’s credentials. In reality, it can ride the already-authenticated connection for the first user. That is not a password disclosure story in the familiar sense; it is an identity confusion story, and those are often harder to detect because the request may look legitimate to the remote service.
The fix in 8.19.0 changes the reuse decision so connections that may use Negotiate cannot reuse another Negotiate-using connection unless the credentials match. That is why the upgrade is more attractive than a blanket “turn off reuse” workaround: it preserves the performance model where safe, while closing the wrong-identity case.
That is still a meaningful audience. Internal enterprise tools, Windows-integrated authentication gateways, service brokers, management agents, proxy-aware automation, and cross-platform clients may all use libcurl underneath without exposing that detail in the UI. One of the recurring frustrations with curl vulnerabilities is that “we do not run curl” is often not the same as “we do not ship libcurl.”
For a single-user desktop tool that authenticates to one service as one identity and exits quickly, the practical risk may be low. For middleware that multiplexes requests for different users, service accounts, tenants, or delegated workflows, the risk is materially higher. The key question is not whether curl is present; it is whether one process can make same-host Negotiate requests using different credentials while reusing connections.
This is where Windows administrators should pay close attention. Negotiate is not an exotic authentication method in Microsoft-heavy networks. If a cross-platform application uses libcurl to talk to an IIS-backed service, an internal API, or an authentication-aware reverse proxy, this bug sits right at the seam between Windows identity infrastructure and portable client code.
Start with software you build or package yourself. Search for uses of
Then move to third-party applications. Ask vendors whether they ship libcurl, which version they ship, and whether HTTP Negotiate is enabled in any integration path. This is especially important for products that quietly act as connectors: backup agents, identity bridges, monitoring collectors, endpoint management clients, file-transfer tools, data-ingestion services, and internal automation platforms.
Finally, examine long-running processes before short-lived scripts. A process that runs for weeks and keeps connections warm has more opportunity to hit a stale authenticated connection than a command that runs once and exits. That does not make the command-line curl tool irrelevant, but it does make daemon-style usage the sharper operational concern.
For applications using the multi interface,
The uncomfortable truth is that all three knobs are substitutes for a corrected reuse decision. They can be sensible interim controls, but each one shifts the performance and concurrency characteristics of the application. In latency-sensitive services, those changes can be visible; in high-throughput services, they can become capacity planning problems.
That does not mean administrators should avoid mitigations. It means they should test them like real production changes rather than treating them as a harmless config toggle. A mitigation that protects identity but overloads a fragile internal service can create a different incident by lunchtime.
The trade-off is most visible in service-to-service architectures. A connector that previously reused a handful of warm authenticated HTTPS connections may begin opening many more connections under
A middle path may be to apply the strongest mitigation only to code paths where credentials change. If a process has one identity for one backend, aggressive reuse restrictions may not buy much. If the same process alternates between identities against the same host, that is where fresh connections or stricter cache controls are worth the cost until 8.19.0 is deployed.
CVE-2026-1965 is what happens when those mental models do not line up. HTTP was designed around requests, but Negotiate can effectively authenticate the connection. Once the connection itself carries authentication state, connection reuse stops being a mere performance optimization and becomes part of the security model.
That is also why the bug is so easy to underestimate. Logs on the server side may simply show a valid authenticated request. The application may not crash. The user may not see a prompt. The dangerous behavior is that the wrong identity may be associated with the right-looking request.
For sysadmins, the immediate question is not “Do we use curl at the command line?” It is “Which applications in our environment use libcurl to talk to integrated-auth endpoints?” That list may include software maintained by teams that do not think of themselves as Windows authentication specialists.
The priority should rise in any environment where one application instance handles requests for multiple users. Think web backends, API gateways, shared automation workers, synchronization services, and internal tools that broker access to a protected service. If the process can move between identities while targeting the same host, patching should move near the front of the queue.
The priority is lower where libcurl is present but Negotiate is not used. It is also lower where each process is tied to one credential set and exits quickly. Even then, the affected version range is long enough that waiting for a routine vendor update without asking questions is not a strategy.
The most practical patch policy is simple: upgrade anything you control to 8.19.0, pressure vendors for their curl/libcurl status, and use reuse-limiting mitigations only as a bridge. If a vendor cannot tell you whether they use Negotiate with libcurl, that uncertainty belongs in your risk register.
The nearby 8.19.0 security set reinforces that point. The curl project fixed multiple issues in the same release, and one of the other disclosed problems also involved mistaken reuse behavior, this time around proxy authentication. For teams already reviewing CVE-2026-1965, the sensible move is to treat 8.19.0 as a broader curl security update rather than a single-defect patch.
There is also historical rhyme here. Earlier libcurl advisories around GSSAPI delegation and connection reuse showed how privilege or authentication state can bleed across requests when reuse rules are too permissive. The lesson is not that curl is uniquely careless; it is that long-lived client libraries become miniature transport platforms, and transport platforms accumulate state.
That is why “just block reuse” should not become the permanent answer. A local workaround may suppress one failure mode while leaving the application dependent on assumptions the library maintainers have already corrected upstream. In infrastructure code, staying close to the fixed release usually beats carrying a private security posture indefinitely.
For internally developed software, the owner should confirm the linked libcurl version in the actual deployed artifact, not just in the build manifest. Containers, statically linked binaries, vendor SDKs, and bundled runtime directories can all preserve older library copies after the host operating system has been patched.
For packaged software, administrators should ask whether the vendor’s fix is a true libcurl update, a backported patch, or a configuration workaround. Backports may be acceptable, but they require clarity. A product that reports an older curl version may still contain the fix, while a product installed on a patched OS may still ship its own vulnerable libcurl.
For temporary mitigations, document exactly where reuse has been restricted and why. That matters because performance workarounds have a habit of becoming invisible technical debt. Once 8.19.0 or an equivalent vendor fix is in place, teams should revisit whether the emergency connection limits are still needed.
That makes ownership the real work. Security teams can identify affected versions, but application owners must explain authentication behavior. Network teams can observe connection churn, but developers must decide whether
The organizations that handle this well will not ask one team to solve it alone. They will pair software inventory with authentication-flow review. They will treat “uses libcurl” and “uses HTTP Negotiate with multiple credentials” as separate findings that become high priority only when combined.
That distinction is important because it keeps the response credible. Panic-patching everything without understanding exposure wastes attention; dismissing the issue because it requires specific conditions misses the environments where those conditions are routine.
The right sequencing is to patch first wherever the dependency is under your control. Use mitigations for software that cannot be patched today, especially when it handles multiple identities against the same host using Negotiate. Remove or relax those mitigations only after you verify that the fixed libcurl is actually in use.
CURLOPT_FRESH_CONNECT, tighter connection-cache limits through CURLOPT_MAXCONNECTS, or per-host limits with CURLMOPT_MAX_HOST_CONNECTIONS when using the multi interface. The catch is that these mitigations are not a clean substitute for the fix: they change connection behavior, can reduce performance, and may not map neatly onto every application’s authentication model.
The Right Answer Is Patch First, Tune Reuse Second
CVE-2026-1965 is not the kind of curl flaw most administrators can safely wave away as a theoretical parser bug in some forgotten protocol corner. It sits in the place where libcurl is most often treated as boring infrastructure: connection reuse. The failure mode is simple enough to be operationally alarming: a later request can reuse a connection authenticated for a different user.That matters because HTTP Negotiate, commonly associated with SPNEGO and Kerberos-style enterprise authentication, is often used precisely where identity boundaries matter. In a domain environment, an internal service may trust that the authenticated connection represents the current user or service account. If libcurl gets that identity wrong, the application can end up sending a request under the wrong authenticated session.
The curl project’s own recommendation order starts with upgrading to curl and libcurl 8.19.0. That should also be the default WindowsForum answer. If you own the application, rebuild or relink against the fixed libcurl; if you consume curl through a distribution, vendor appliance, SDK, package manager, or embedded runtime, track that supply chain until the fixed version actually lands in your deployed stack.
Blocking Negotiate reuse is a useful emergency brake. It is not the same thing as repairing the steering.
This Is a Connection-Pool Bug With an Identity Problem
libcurl keeps a pool of recent connections because opening new TCP and TLS sessions for every request is expensive. That behavior is usually a feature. It reduces latency, lowers server load, and lets applications make repeated calls without paying the full handshake cost every time.CVE-2026-1965 turns that optimization into a security boundary problem. The vulnerable versions can decide that an existing connection to the same server is reusable even when that connection was authenticated using different credentials. In the specific scenario described by the curl advisory, an application uses Negotiate authentication as one user, then performs another Negotiate-authenticated operation to the same server as another user while the previous connection is still alive.
The second request may believe it is operating with the second user’s credentials. In reality, it can ride the already-authenticated connection for the first user. That is not a password disclosure story in the familiar sense; it is an identity confusion story, and those are often harder to detect because the request may look legitimate to the remote service.
The fix in 8.19.0 changes the reuse decision so connections that may use Negotiate cannot reuse another Negotiate-using connection unless the credentials match. That is why the upgrade is more attractive than a blanket “turn off reuse” workaround: it preserves the performance model where safe, while closing the wrong-identity case.
The Risk Is Narrower Than “Everyone With curl,” but Wider Than “Only curl Power Users”
The affected range is broad: curl 7.10.6 through 8.18.0. That sounds sweeping because libcurl is everywhere, but the exploitable condition is more specific. Your stack needs to use HTTP or HTTPS with Negotiate authentication, and it needs a pattern where multiple credentials or identities can target the same host while connections remain reusable.That is still a meaningful audience. Internal enterprise tools, Windows-integrated authentication gateways, service brokers, management agents, proxy-aware automation, and cross-platform clients may all use libcurl underneath without exposing that detail in the UI. One of the recurring frustrations with curl vulnerabilities is that “we do not run curl” is often not the same as “we do not ship libcurl.”
For a single-user desktop tool that authenticates to one service as one identity and exits quickly, the practical risk may be low. For middleware that multiplexes requests for different users, service accounts, tenants, or delegated workflows, the risk is materially higher. The key question is not whether curl is present; it is whether one process can make same-host Negotiate requests using different credentials while reusing connections.
This is where Windows administrators should pay close attention. Negotiate is not an exotic authentication method in Microsoft-heavy networks. If a cross-platform application uses libcurl to talk to an IIS-backed service, an internal API, or an authentication-aware reverse proxy, this bug sits right at the seam between Windows identity infrastructure and portable client code.
The Fast Triage Starts With Authentication Shape, Not Version Banners
Version inventory is necessary, but it is not sufficient. The first triage pass should identify applications that both include affected libcurl versions and use HTTP Negotiate. The second pass should separate single-identity clients from multi-identity clients, because the latter are where the bug becomes dangerous.Start with software you build or package yourself. Search for uses of
CURLOPT_HTTPAUTH and check whether Negotiate is enabled. Review whether the same easy handle, share setup, multi handle, or connection cache can be used across requests with different usernames, passwords, tokens, service accounts, or delegated identities.Then move to third-party applications. Ask vendors whether they ship libcurl, which version they ship, and whether HTTP Negotiate is enabled in any integration path. This is especially important for products that quietly act as connectors: backup agents, identity bridges, monitoring collectors, endpoint management clients, file-transfer tools, data-ingestion services, and internal automation platforms.
Finally, examine long-running processes before short-lived scripts. A process that runs for weeks and keeps connections warm has more opportunity to hit a stale authenticated connection than a command that runs once and exits. That does not make the command-line curl tool irrelevant, but it does make daemon-style usage the sharper operational concern.
The Mitigations Work by Making Reuse Less Clever
If upgrading immediately is impossible, the official mitigations all aim at the same basic principle: prevent or constrain the connection reuse that lets the wrong authenticated connection be selected.CURLOPT_FRESH_CONNECT tells libcurl to use a new connection for the next transfer instead of trying to reuse an existing one. In the most sensitive paths, that is the bluntest and easiest-to-reason-about mitigation.CURLOPT_MAXCONNECTS limits how many idle connections libcurl keeps in its cache. A smaller cache reduces the odds that an old authenticated connection remains available for accidental reuse. It is less absolute than forcing a fresh connection, but it may be more tolerable for applications that would suffer badly if every request paid the full connection setup cost.For applications using the multi interface,
CURLMOPT_MAX_HOST_CONNECTIONS can limit how many connections are allowed to a single host. That can help reduce connection-pool ambiguity in busy clients, particularly where many transfers target the same internal endpoint. It is not a magic identity partition, though; it is still a connection-management control, not an authentication fix.The uncomfortable truth is that all three knobs are substitutes for a corrected reuse decision. They can be sensible interim controls, but each one shifts the performance and concurrency characteristics of the application. In latency-sensitive services, those changes can be visible; in high-throughput services, they can become capacity planning problems.
Turning Off Reuse Can Be Safer and Still Hurt
There is a reason connection reuse exists. New connections cost time, CPU, network round trips, TLS negotiation, server resources, and sometimes scarce ephemeral ports. When an application suddenly stops reusing connections, the symptom may show up as slower requests, higher backend load, or a mysterious increase in connection churn.That does not mean administrators should avoid mitigations. It means they should test them like real production changes rather than treating them as a harmless config toggle. A mitigation that protects identity but overloads a fragile internal service can create a different incident by lunchtime.
The trade-off is most visible in service-to-service architectures. A connector that previously reused a handful of warm authenticated HTTPS connections may begin opening many more connections under
CURLOPT_FRESH_CONNECT. If that connector fans out across users or tenants, the security argument for fresh connections is strong, but the capacity impact should be measured.A middle path may be to apply the strongest mitigation only to code paths where credentials change. If a process has one identity for one backend, aggressive reuse restrictions may not buy much. If the same process alternates between identities against the same host, that is where fresh connections or stricter cache controls are worth the cost until 8.19.0 is deployed.
The Windows Angle Is Identity Delegation by Another Name
Windows shops should read this advisory less as a curl-only maintenance notice and more as a reminder that enterprise authentication assumptions leak across abstraction layers. An administrator may think in terms of users, service accounts, Kerberos, IIS, and domain policy. The application developer may think in terms of URLs, handles, connection pools, and HTTP auth flags.CVE-2026-1965 is what happens when those mental models do not line up. HTTP was designed around requests, but Negotiate can effectively authenticate the connection. Once the connection itself carries authentication state, connection reuse stops being a mere performance optimization and becomes part of the security model.
That is also why the bug is so easy to underestimate. Logs on the server side may simply show a valid authenticated request. The application may not crash. The user may not see a prompt. The dangerous behavior is that the wrong identity may be associated with the right-looking request.
For sysadmins, the immediate question is not “Do we use curl at the command line?” It is “Which applications in our environment use libcurl to talk to integrated-auth endpoints?” That list may include software maintained by teams that do not think of themselves as Windows authentication specialists.
8.19.0 Deserves Priority Even in Crowded Patch Windows
Every security team has a backlog, and a medium-severity authentication bypass may have to compete with louder vulnerabilities. But this one deserves a closer look because the blast radius is not captured by CVSS-style severity alone. Identity confusion bugs can create data-access mistakes that are quiet, contextual, and difficult to reconstruct after the fact.The priority should rise in any environment where one application instance handles requests for multiple users. Think web backends, API gateways, shared automation workers, synchronization services, and internal tools that broker access to a protected service. If the process can move between identities while targeting the same host, patching should move near the front of the queue.
The priority is lower where libcurl is present but Negotiate is not used. It is also lower where each process is tied to one credential set and exits quickly. Even then, the affected version range is long enough that waiting for a routine vendor update without asking questions is not a strategy.
The most practical patch policy is simple: upgrade anything you control to 8.19.0, pressure vendors for their curl/libcurl status, and use reuse-limiting mitigations only as a bridge. If a vendor cannot tell you whether they use Negotiate with libcurl, that uncertainty belongs in your risk register.
The Fix Also Exposes a Bigger curl Pattern
WindowsForum readers have seen this class of libcurl issue before. Connection reuse is a recurring source of subtle security failures because libcurl supports many protocols, authentication methods, proxies, caches, and application models. The library’s strength is that it abstracts all of this complexity; the danger is that abstractions sometimes hide where identity state actually lives.The nearby 8.19.0 security set reinforces that point. The curl project fixed multiple issues in the same release, and one of the other disclosed problems also involved mistaken reuse behavior, this time around proxy authentication. For teams already reviewing CVE-2026-1965, the sensible move is to treat 8.19.0 as a broader curl security update rather than a single-defect patch.
There is also historical rhyme here. Earlier libcurl advisories around GSSAPI delegation and connection reuse showed how privilege or authentication state can bleed across requests when reuse rules are too permissive. The lesson is not that curl is uniquely careless; it is that long-lived client libraries become miniature transport platforms, and transport platforms accumulate state.
That is why “just block reuse” should not become the permanent answer. A local workaround may suppress one failure mode while leaving the application dependent on assumptions the library maintainers have already corrected upstream. In infrastructure code, staying close to the fixed release usually beats carrying a private security posture indefinitely.
The Operational Plan Should Be Boring on Purpose
The best response to CVE-2026-1965 is a deliberately plain one. Inventory, patch, mitigate where patching lags, and test the performance consequences. There is no need to dramatize the bug into a universal emergency, but there is also no excuse for ignoring it in multi-user Negotiate deployments.For internally developed software, the owner should confirm the linked libcurl version in the actual deployed artifact, not just in the build manifest. Containers, statically linked binaries, vendor SDKs, and bundled runtime directories can all preserve older library copies after the host operating system has been patched.
For packaged software, administrators should ask whether the vendor’s fix is a true libcurl update, a backported patch, or a configuration workaround. Backports may be acceptable, but they require clarity. A product that reports an older curl version may still contain the fix, while a product installed on a patched OS may still ship its own vulnerable libcurl.
For temporary mitigations, document exactly where reuse has been restricted and why. That matters because performance workarounds have a habit of becoming invisible technical debt. Once 8.19.0 or an equivalent vendor fix is in place, teams should revisit whether the emergency connection limits are still needed.
The Decision Tree Is Short, but the Ownership Trail Is Not
The central decision is easy: upgrade where you can. The hard part is proving where “you can” ends. libcurl can live in source trees, package dependencies, plugins, appliances, developer tools, language bindings, and third-party Windows applications that never mention curl in their product name.That makes ownership the real work. Security teams can identify affected versions, but application owners must explain authentication behavior. Network teams can observe connection churn, but developers must decide whether
CURLOPT_FRESH_CONNECT is safe for a given path. Windows administrators can recognize Negotiate, but vendors must disclose how their clients use it.The organizations that handle this well will not ask one team to solve it alone. They will pair software inventory with authentication-flow review. They will treat “uses libcurl” and “uses HTTP Negotiate with multiple credentials” as separate findings that become high priority only when combined.
That distinction is important because it keeps the response credible. Panic-patching everything without understanding exposure wastes attention; dismissing the issue because it requires specific conditions misses the environments where those conditions are routine.
The Practical Answer for This Patch Window
CVE-2026-1965 is a decision point because both paths have costs. Upgrading to 8.19.0 requires build, vendor, and deployment work. Blocking reuse can protect the riskiest cases sooner, but it may slow applications or alter connection behavior in ways that need testing.The right sequencing is to patch first wherever the dependency is under your control. Use mitigations for software that cannot be patched today, especially when it handles multiple identities against the same host using Negotiate. Remove or relax those mitigations only after you verify that the fixed libcurl is actually in use.
- Upgrade curl and libcurl to 8.19.0 for any application that uses HTTP Negotiate/SPNEGO and can reach the same host with more than one credential set.
- Use
CURLOPT_FRESH_CONNECTon sensitive transfers when you need the clearest temporary barrier against reusing an authenticated connection. - Reduce idle connection reuse with
CURLOPT_MAXCONNECTSwhen a full fresh-connection policy is too expensive but the application still needs a short-term risk reduction. - Use
CURLMOPT_MAX_HOST_CONNECTIONSin multi-interface applications to constrain same-host connection behavior while you test and deploy the fixed library. - Treat vendor statements carefully, because a patched operating system does not guarantee that a bundled application has stopped using an affected libcurl build.
- Prioritize long-running, multi-user, same-host Negotiate clients ahead of short-lived single-identity tools.
References
- Primary source: curl.se
Vulnerabilities in curl 8.19.0
curl.se
- Independent coverage: sentinelone.com
CVE-2026-1965: Haxx Curl Auth Bypass Vulnerability
CVE-2026-1965 is an authentication bypass vulnerability in Haxx Curl. Learn about its impact, affected versions, and mitigation methods.www.sentinelone.com
- Independent coverage: prohoster.info
🥇curl 8.19.0 | ProHoster
On March 11th, after more than two months of development and 538 commits, version 8.19.0 (the 273rd) of the cross-platform curl command-line utility and library, written in C and distributed under the curl license, was released. Key Changes: Security: The vulnerability bounty program has been...prohoster.info - Independent coverage: techdrop.one
curl 8.19.0 Patches Four Security Vulnerabilities Including SMB Use-After-Free | TechDrop
The curl project has released version 8.19.0 with fixes for four security vulnerabilities, including CVE-2026-3805 — a use-after-free bug in SMB connection reus...www.techdrop.one - Independent coverage: feedly.com
CVE-2026-1965 - Exploits & Severity - Feedly
libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of...feedly.com - Independent coverage: news.lavx.hu
CVE-2026-5545: curl Fixes Wrong HTTP Negotiate Connection Reuse | LavX News
curl and libcurl versions 7.10.6 through 8.19.0 can reuse an authenticated connection under the wrong credentials. Upgrade now.
news.lavx.hu
- Independent coverage: redpacketsecurity.com
- Independent coverage: daniel.haxx.se
curl 8.19.0 | daniel.haxx.se
Release presentation https://www.youtube.com/watch?v=5XoJTh99bPg Numbers the 273rd release8 changes63 days (total: 10,712)264 bugfixes (total: 13,640)538 commits (total: 38,024)0 new public libcurl function (total: 100)0 new curl_easy_setopt() option (total: 308)0 new curl command line option...daniel.haxx.se - Primary source: WindowsForum
CVE-2026-1965: libcurl Negotiate auth flaw fixed in 8.19.0 | Windows Forum
libcurl's Negotiate authentication code has a logic flaw that can cause a request to reuse a connection authenticated for a different user, exposing...windowsforum.com
