CVE-2025-14524: 
cURL vulnerability analysis and mitigation

CVE-2025-14524 is a bearer token leak vulnerability in curl caused by improper handling of OAuth2 tokens during cross-protocol redirects. When curl performs an HTTP(S) transfer using an OAuth2 bearer token and follows a redirect to a URL using IMAP, LDAP, POP3, or SMTP, it may incorrectly forward the bearer token to the new target host. The vulnerability affects curl versions 7.33.0 through 8.17.0 (inclusive), and was reported on December 9, 2025, with a coordinated disclosure and patch released on January 7, 2026. It carries a CVSS v3.1 base score of 5.3 (Medium) (curl Advisory, Openwall OSS-Sec).

The root cause is classified as CWE-522 (Insufficiently Protected Credentials) by the curl project, though NVD also maps it to CWE-601 (URL Redirection to Untrusted Site). The flaw was introduced in commit 06c1bea72faabb6fad4b7ef8 and occurs when curl is configured to allow cross-protocol redirects (non-default behavior) and the redirect target URL includes a username component but no password — a combination that triggers the erroneous token forwarding. Exploitation requires the user to have explicitly enabled redirects to non-HTTP protocols (IMAP, LDAP, POP3, or SMTP) and to be using OAuth2 bearer authentication, making this a highly unusual but possible configuration. The fix was applied in commit 1a822275d333dc6da6043497160fd and the original report is available via HackerOne (curl Advisory, HackerOne Report).

Successful exploitation results in the unintentional disclosure of an OAuth2 bearer token to an unintended server (e.g., an attacker-controlled IMAP or SMTP server), constituting a high-confidentiality impact with no integrity or availability impact. The leaked token could be used by an attacker to impersonate the victim in subsequent authenticated API or service calls, potentially enabling account takeover or unauthorized data access. The vulnerability affects both the curl command-line tool and libcurl, meaning any application embedding libcurl with the described configuration is also at risk (curl Advisory, Openwall OSS-Sec).

1. Identify a target: Find an application or system using curl/libcurl versions 7.33.0–8.17.0 with OAuth2 bearer token authentication and cross-protocol redirects explicitly enabled (e.g., via CURLOPT_FOLLOWLOCATION combined with CURLOPT_REDIR_PROTOCOLS allowing IMAP/LDAP/POP3/SMTP).
2. Set up a malicious server: Deploy a server that responds to an initial HTTP(S) request with a redirect (HTTP 301/302) pointing to an attacker-controlled IMAP, LDAP, POP3, or SMTP URL that includes a username component (e.g., imap://attacker@malicious.example.com/).
3. Trigger the redirect: Cause the vulnerable curl client to make an HTTP(S) request to the attacker-controlled or compromised HTTP server (e.g., via a crafted link, SSRF, or man-in-the-middle position).
4. Capture the bearer token: The vulnerable curl client follows the cross-protocol redirect and forwards the OAuth2 bearer token in the Authorization header to the attacker's IMAP/LDAP/POP3/SMTP server, where it can be logged and captured.
5. Abuse the token: Use the captured bearer token to authenticate to the legitimate service on behalf of the victim, enabling unauthorized access to protected resources (curl Advisory, HackerOne Report).

• Network: Outbound connections from a curl/libcurl client to unexpected IMAP (port 143/993), LDAP (port 389/636), POP3 (port 110/995), or SMTP (port 25/465/587) servers following an HTTP(S) request; Authorization: Bearer <token> headers observed in non-HTTP protocol traffic.
• Logs: Application or proxy logs showing HTTP redirect responses (301/302) with Location: headers pointing to imap://, ldap://, pop3://, or smtp:// URLs; curl verbose logs (-v) showing bearer token forwarded after a protocol change.
• Process/Configuration: curl or libcurl invocations with --location (follow redirects) combined with --proto-redir or CURLOPT_REDIR_PROTOCOLS flags permitting non-HTTP protocols, alongside --oauth2-bearer or equivalent API usage.

The primary remediation is to upgrade curl to version 8.18.0 or later, which contains the fix (curl Advisory). If immediate upgrade is not possible, three workarounds are available: (A) disable cross-protocol redirects (do not enable CURLOPT_REDIR_PROTOCOLS for IMAP/LDAP/POP3/SMTP — this is the default behavior and the safest option), (B) avoid using OAuth2 bearer tokens in contexts where redirects are followed, or (C) restrict redirect targets to HTTP(S) only. Downstream vendors including Apple (iOS, macOS, visionOS, tvOS — March 2026 updates) and IBM (AIX, MQ Operator container images — April/May 2026) have released platform-specific patches (Apple Advisory, IBM Advisory).

The curl project lead Daniel Stenberg patched and disclosed the vulnerability coordinated with the curl 8.18.0 release on January 7, 2026, and posted a blog entry summarizing the release (Daniel Stenberg Blog). The issue was discussed on the oss-security mailing list and noted by security researchers on Mastodon and Bluesky shortly after disclosure. The vulnerability was characterized by the curl team as a "highly unusual combination" of conditions, and rated Low severity by the project itself — though CISA-ADP assigned a Medium CVSS score. Community reaction was measured, with most commentary focused on the narrow exploitation prerequisites and the availability of a straightforward patch (Openwall OSS-Sec).