CVE-2026-5545

What it actually does

This is a libcurl connection-reuse authentication confusion flaw. When an application performs an HTTP or HTTPS request using Negotiate authentication and then makes another authenticated request to the same host using different credentials while the first connection remains alive, libcurl may incorrectly reuse the existing authenticated connection. The second request can therefore be sent over a connection still authenticated as the first user, causing the server to process the request under the wrong identity. The primary impact is authorization bypass and unintended actions as another principal, with possible limited data exposure depending on what the application requests and what the server returns.

Why it matters to the business

Applications that use libcurl to communicate with HTTP(S) services may perform operations as the wrong user when they reuse connections across different credentials. In business terms, this can lead to incorrect account actions, unauthorized changes, audit inaccuracies, and potential exposure of user-specific information. The issue is not currently listed in CISA KEV and has a low EPSS score, but exploit code is reported as available, so internet-facing services, multi-user systems, proxies, automation platforms, and applications that mix credentials against the same destination should be prioritized for review.

How an attack unfolds

An attacker generally needs a way to influence or trigger an application that uses libcurl to make multiple authenticated requests to the same HTTP(S) host with different credentials. The vulnerable sequence begins when the application authenticates to a server using Negotiate authentication as one user and keeps the connection open in libcurl’s connection pool. The attacker then causes or waits for the application to make a subsequent authenticated request to the same host using a different user identity. Because of the connection matching logic error, libcurl may select the existing Negotiate-authenticated connection instead of creating or selecting a connection appropriate for the second identity. The server then receives the second request over a connection that is still authenticated as the first user, so the requested action or data access may occur under the wrong account. This is most relevant in client applications, service integrations, API gateways, daemons, or automation systems that reuse libcurl handles or connection pools across users, tenants, jobs, or credential contexts.

How to fix it

Upgrade curl/libcurl to a vendor-provided fixed version as soon as it is available for the affected platform. Because no exact fixed version was provided in the input, use the operating system, container base image, language runtime, appliance, or embedded product advisory as the source of truth, and ensure applications linked against libcurl are rebuilt or restarted after updating. As interim mitigations, avoid reusing the same libcurl connection pool across different user identities, credentials, or authentication methods; isolate curl handles by identity; disable connection reuse for sensitive multi-user flows using options such as CURLOPT_FRESH_CONNECT and CURLOPT_FORBID_REUSE where practical; close connections after Negotiate-authenticated requests; and disable Negotiate authentication if it is not required. Review applications that multiplex requests for multiple users to the same upstream host, as they are the highest-risk usage pattern.

How to confirm the fix worked

Confirm exposure by inventorying all curl/libcurl packages, statically linked binaries, containers, appliances, and language bindings that depend on libcurl. Verify the installed package version against the vendor advisory for CVE-2026-5545 and confirm that running processes have been restarted so they are using the patched library. For functional validation, test an application workflow that sends a Negotiate-authenticated request as one user followed by another authenticated request to the same host as a different user while keep-alive is enabled; after remediation, the second request should authenticate and be authorized only as the second user or should use a separate correctly authenticated connection. Enable libcurl verbose/debug logging or application HTTP client tracing in a test environment to confirm that connection reuse does not cross credential boundaries.

Typical attack path

1. Identify or interact with an application that uses libcurl for HTTP(S) requests and supports multiple credential contexts to the same host.
2. Trigger or rely on a request that authenticates to the target host using Negotiate authentication as one user while the connection remains reusable.
3. Trigger a second request to the same host using different credentials or a different authentication method before the first connection is closed.
4. Cause libcurl to incorrectly reuse the existing Negotiate-authenticated connection from the first request.
5. Have the server process the second request under the wrong authenticated identity.
6. Use the identity confusion to perform unauthorized actions, corrupt business records, or retrieve data associated with the wrong account.

How to detect it

There is no universal network signature for successful exploitation because the vulnerable behavior occurs inside the client-side libcurl connection-selection logic and the HTTP traffic may look like legitimate authenticated traffic. To investigate possible exploitation, correlate application request logs, upstream service access logs, identity provider logs, Kerberos or SPNEGO authentication events, and application audit trails. Look for sequences where the same client process or source address connects to the same HTTP(S) host using Negotiate authentication as one identity, then immediately performs an action that the application intended to execute as a different identity, while the upstream service records the action as the first identity. Pay special attention to keep-alive connections, reused HTTP(S) sessions, unexpected account attribution, mismatches between application-level intended user and upstream authenticated user, and sensitive write operations performed by an identity that does not match the initiating workflow. In forensic review, examine libcurl verbose logs if available for connection reuse messages around credential changes, but absence of such logs does not prove non-exploitation.

What your security team should do

• Prioritize inventory of applications and services that use libcurl for authenticated HTTP(S), especially multi-user services, API brokers, automation platforms, gateways, and integrations that connect to the same host with different credentials.
• Patch curl/libcurl through vendor-supported channels and restart or redeploy dependent applications, containers, and services.
• Identify statically linked applications or embedded products that bundle libcurl; these require vendor updates or rebuilds rather than only operating system package updates.
• Apply interim mitigations by isolating connection pools per identity and disabling connection reuse for Negotiate-authenticated or mixed-credential workflows until patched.
• Review application audit logs for actions performed by one account immediately after requests were expected to run as a different account against the same upstream service.
• Add regression tests for credential isolation in HTTP client code that reuses libcurl handles, connection pools, or shared objects.
• Monitor vendor advisories for exact fixed versions and backported package names because fixed versions were not provided in the input.
• Treat exploit availability as a reason to remediate deliberately, but weigh urgency against the currently low EPSS score and absence from CISA KEV.