Authorization Header Reuse in libcurl

Executive Summary

CVE-2026-11856 is a vulnerability in libcurl where reusing a handle to perform a transfer to one HTTP origin (hostA) with Digest authentication and then switching to a different origin (hostB) causes libcurl to incorrectly send the Authorization header meant for hostA to hostB.

This means that the authenticated state intended for hostA is mistakenly passed to hostB, allowing hostB to impersonate the client when communicating with hostA. However, hostB cannot see the details of hostA, and the credentials themselves are not exposed, only the ability to replay the specific request for the exact path.

The vulnerability is classified as CWE-294 (Authentication Bypass by Capture-replay) with medium severity and affects libcurl versions 7.10.6 through 8.20.0. It was fixed in version 8.21.0.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability involves libcurl incorrectly sending an Authorization header meant for one HTTP origin (hostA) to a different origin (hostB) when reusing the same handle with Digest authentication.

To detect this issue on your network or system, you can monitor HTTP traffic for unexpected Authorization headers being sent to origins different from the authenticated host.

A practical approach is to capture and inspect HTTP requests using tools like tcpdump or Wireshark, filtering for HTTP Authorization headers and verifying if they are sent to multiple different hosts within the same session or connection reuse.

• Use tcpdump to capture HTTP traffic on port 80 or 443 (if unencrypted or decrypted): tcpdump -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
• Use Wireshark to filter HTTP requests with Authorization headers: http.authheader
• Manually review captured HTTP requests to check if the Authorization header intended for one host is being sent to a different host.

Note that this vulnerability does not affect the curl command line tool and is specific to libcurl library usage with reused handles across different origins.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can allow an unintended server (hostB) to receive and reuse the Authorization header intended for another server (hostA), effectively letting hostB impersonate the client in requests meant for hostA.

While the actual credentials are not exposed, the attacker controlling hostB can replay the authenticated request for the exact path, potentially gaining unauthorized access or causing unintended actions on hostA.

The impact is limited because hostB cannot see the details of hostA or the credentials themselves, but the authentication bypass by replaying requests can still lead to security risks.

Useful 0 Not Useful 0

Compliance Impact

This vulnerability causes libcurl to send an Authorization header intended for one HTTP origin (hostA) to a different origin (hostB) when reusing the same handle. While this can allow hostB to impersonate the client for hostA, the credentials themselves are not exposed, and hostB cannot see the details of hostA. The impact is limited to replaying a specific authenticated request.

Because the vulnerability involves potential unauthorized reuse of authentication headers, it could pose risks related to unauthorized access or data exposure, which are relevant concerns under standards like GDPR and HIPAA that require protection of sensitive data and authentication credentials.

However, the provided information does not explicitly discuss compliance implications or how this vulnerability directly affects adherence to these regulations.

Useful 0 Not Useful 0

Mitigation Strategies

To mitigate this vulnerability, users should upgrade libcurl to version 8.21.0 or later where the issue is fixed.

Alternatively, users can apply the available patch that addresses this issue.

As a temporary workaround, avoid reusing the same libcurl handle when switching between different HTTP origins.

Useful 0 Not Useful 0