✓ProveIt
Examples / Report #3514263 Saved analysis

libcurl: Improper Authentication State Management on Cross-Protocol Redirects

curl · 2026-01-1719.2s analysis · $0.017 in model calls

What the report claims

libcurl fails to clear OAuth2 Bearer tokens during cross-protocol redirects, allowing token leakage to attacker-controlled services.

Compare with curl's recorded outcome

Labeled AI slop

curl's maintainer lists this report as AI slop

Shown for comparison after analysis. The pipeline did not see this label.

ProveIt's finding

Needs human review

The available evidence does not settle the report. A maintainer should investigate.

Why this finding?
  • The critical file lib/http.c containing the redirect credential-clearing logic is not included in the provided source code sections.
  • Deterministic checks confirm lib/http.c exists and the two quoted Curl_safefree lines appear in the codebase, but do not confirm their context (i.e., that they are in the redirect clearing path and that the Bearer token is omitted).
  • The report's central claim is plausible and specific, citing exact lines and a concrete attack path, but the provided code does not allow a decision either way.
  • No project policy section applies; if the flaw exists as described, it would be a security issue (credential exfiltration across security boundaries).
What still needs checking
  • The content of lib/http.c around the redirect handling code that clears credentials (the 'clear' block cited in the report).
  • The definition of STRING_BEARER and where CURLOPT_XOAUTH2_BEARER is stored in the easy handle.
  • The IMAP/SASL code path that reads the Bearer token for authentication.
How this analysis ran 5 claims · 0 citations verified

Checked against curl master on 2026-01-17 (6c8956c1cbf5). Test evaluation split. Citation verification checks that a referenced line was in the evidence; it does not prove the model interpreted it correctly.

1 · Grounding
grounded
no model · 5 references checked out, 0 did not
2 · Claims
NVIDIA-Nemotron-3-Nano-30B-A3B
5 claims · 2735 tokens · $0.0003
3 · Evidence
1 code snippets
real curl source at 6c8956c1cbf5 · 6 docs via Tavily
4 · Judgment
Nemotron-3-Ultra-550b-a55b
10511 tokens · 9.8s · $0.0163
5 · Receipts
0 of 0 citations verified
every citation must point at code the judge was shown
Review a draft reply to the reporter

Edit and verify before sending.

Thank you for the detailed report and PoC. The claim is plausible and well-scoped. However, the triage context provided to me does not include the content of lib/http.c where the redirect credential-clearing logic resides. Could you point to the exact function and line range in lib/http.c (at revision 6c8956c1cbf5) where the 'clear' block runs during redirects? With that code visible, I can verify whether the Bearer token (stored via CURLOPT_XOAUTH2_BEARER) is omitted from the clearing operation.

Inspect all claims and source code 5 claims · 1 code excerpts

Report claims

C1flaw not verifiable

OAuth2 Bearer token is not cleared during cross-protocol redirects

Read the reasoning

The report claims OAuth2 Bearer token is not cleared during cross-protocol redirects, citing lib/http.c. However, the content of lib/http.c is not provided in the source code sections. The deterministic checks confirm the file exists and the two quoted Curl_safefree lines appear somewhere in the codebase, but they do not confirm these lines are in the redirect clearing logic or that the Bearer token is stored separately and omitted from clearing. Without the actual redirect handling code, this claim cannot be verified.

C2location not verifiable

The clearing logic only targets standard user/password fields

Read the reasoning

The claim that clearing logic only targets user/password fields relies on seeing the full clearing block in lib/http.c. The provided source code does not include lib/http.c, so the scope of the clearing logic cannot be confirmed.

C3impact not verifiable

Bearer token survives the clear operation and is sent to new destinations

Read the reasoning

The claim that the Bearer token survives the clear operation and is sent to new destinations depends on (a) the token being stored in CURLOPT_XOAUTH2_BEARER / data->set.str[STRING_BEARER], (b) the redirect code not clearing it, and (c) the subsequent protocol (IMAP/SASL) reading it. The deterministic checks confirm CURLOPT_XOAUTH2_BEARER exists, but the redirect handling and SASL code paths are not provided.

C4trigger not verifiable

A 301/302 redirect to a different protocol (e.g., imap://) initiates the leak

Read the reasoning

The trigger condition (301/302 redirect to different protocol with CURLOPT_REDIR_PROTOCOLS_STR allowing it) is plausible per the API, but the code that processes redirects and decides whether to clear credentials is in lib/http.c, which is not provided.

C5reproduction not verifiable

Client sends token to redirector, which redirects to IMAP server that captures SASL authentication

Read the reasoning

The reproduction steps describe a plausible attack chain, but whether it actually works depends on the unverified code paths in lib/http.c and the IMAP/SASL implementation. The PoC code itself is not curl source code and cannot be used as evidence of curl's behavior.

What the report says about other projects

not addressed OAuth2 Bearer tokens must be cleared when crossing security boundaries

not addressed Cross-protocol redirects must invalidate all authentication state

Read the original report (excerpt)

Full report on HackerOne ↗

Following the recent advisory for **CVE-2025-14524**, I conducted an investigation into how libcurl manages OAuth2 credentials during complex redirect chains. I have confirmed that while the library successfully protects traditional user credentials, it fails to clear OAuth2 Bearer tokens in the same way during cross-protocol or cross-origin redirects. This report provides a detailed analysis and a working reproduction of how an attacker can leverage this state-management flaw to exfiltrate valid Bearer tokens. **AI Statement**: This report was researched and generated with the assistance of an AI agent to analyze the libcurl source code and identify inconsistent state management logic. However, the vulnerability has been manually verified, the Proof of Concept code was compiled and executed locally, and the findings have been confirmed against a custom TCP server to ensure validity and reproducibility. ## Vulnerability Description The core issue is an inconsistency in libcurl's security boundary logic. When a request is redirected to a different host, port, or protocol, libcurl correctly invokes a "clear" operation on authentication state to prevent credential leakage (behavior hardened during the fix for CVE-2022-27774). However, my analysis shows that this clearing logic is incomplete as it only targets standard user/password fields. Because the OAuth2 Bearer token (`CURLOPT_XOAUTH2_BEARER`) is stored separately in the handle's configuration, it survives the "clear" operation. When the transfer continues to the new destination, libcurl sees a valid Bearer token and automatically includes it in the new session's headers or SASL handshake. ### Attack Scenario 1. **Victim Initialization**: An application initiates a trusted request (e.g., to an internal API) with `CURLOPT_XOAUTH2_BEARER` set and `CURLOPT_FOLLOWLOCATION` enabled. 2. **The Hook**: A malicious or compromised server returns a `301/302` redirect pointing to an attacker-controlled service using a different protocol (e.g., `imap://`). 3. **The Leak**: libcurl follows the redirect. While it clears standard password credentials, the Bearer token remains. Upon connecting to the IMAP server, libcurl attempts SASL authentication and sends the token to the attacker. ## Proof of Concept I have built a custom environment to demonstrate the leak. This consists of a multi-protocol listener and a stand …

Source code

lib/curl_setup.hlines 936–940 · definition of Curl_safefree
936#define Curl_safefree(ptr) \
937 do { \
938 curlx_free(ptr); \
939 (ptr) = NULL; \
940 } while(0)