CVE-2026-3783

What it actually does

curl/libcurl can incorrectly forward an OAuth2 bearer token to a different hostname during an HTTP(S) redirect when bearer-token authentication is used together with .netrc handling and the redirect target matches a .netrc `machine` entry or the `.netrc` file contains a `default` entry. The result is credential exposure: an access token intended for the original host may be sent in an `Authorization: Bearer ...` header to the redirected host. The impact is confidentiality-only; the vulnerability does not directly provide code execution, privilege escalation, or service disruption.

Why it matters to the business

Applications, automation, CI/CD jobs, integrations, and command-line workflows that use curl with OAuth2 bearer tokens may unintentionally disclose API tokens to another server after following a redirect. If the leaked token is still valid, an attacker or unintended third-party service could use it to access protected APIs or data within the token’s scope. Current public exploitation signals are low: EPSS is 0.00333 with no 30-day increase, it is not listed in CISA KEV, and no mature public exploit is reported; however, the issue is still important where curl is used in high-volume automation or with broadly scoped, long-lived tokens.

How an attack unfolds

An attacker first needs a way to cause a curl/libcurl request that includes an OAuth2 bearer token to receive a redirect to a second hostname. This can happen if the attacker controls the originally requested URL, compromises or influences a redirecting service, poisons a URL used by automation, or otherwise induces a request to an endpoint that returns a crafted `Location` header. The victim’s curl invocation or libcurl-based application must follow redirects and must be using bearer-token authentication along with .netrc processing. If the redirected hostname has a matching `.netrc` `machine` entry, or the `.netrc` file contains a `default` entry, the vulnerable curl behavior can send the original host’s bearer token to the redirected host. If the attacker controls or can observe the redirected destination, they capture the `Authorization: Bearer` header and can then replay the token against the service it was meant for, subject to token validity, scope, audience restrictions, and expiration.

How to fix it

Upgrade curl/libcurl to a vendor-fixed version as soon as one is available from the operating system, container image, language runtime, appliance, or package maintainer. No exact fixed version was provided in the input, so remediation should be tracked through the relevant curl/haxx curl advisories and downstream package channels. Until patched, avoid combining OAuth2 bearer tokens, redirect following, and `.netrc` processing for untrusted URLs. For command-line curl, avoid `--location` with `--oauth2-bearer` and `--netrc`/`--netrc-optional` when redirects may cross hostnames. For libcurl applications, review use of `CURLOPT_FOLLOWLOCATION`, `CURLOPT_XOAUTH2_BEARER`, and `CURLOPT_NETRC`. Remove unnecessary `.netrc` `default` entries, restrict `.netrc` use to trusted hosts, avoid storing sensitive tokens in reusable configuration, and validate redirect destinations before resending authenticated requests. Rotate any bearer tokens that may have been exposed, especially long-lived or broadly scoped tokens.

How to confirm the fix worked

Inventory systems, containers, build images, scripts, and applications that invoke curl or link against libcurl. Confirm installed versions using `curl --version` and package-manager metadata, then compare against the fixed version published by the relevant vendor once available. Review command lines and code for combinations of OAuth2 bearer tokens, redirect following, and `.netrc` usage, including `--oauth2-bearer`, `--location`, `--netrc`, `--netrc-optional`, `CURLOPT_XOAUTH2_BEARER`, `CURLOPT_FOLLOWLOCATION`, and `CURLOPT_NETRC`. To validate behavior safely, use a controlled test with one local endpoint returning a redirect to a second local hostname and inspect the second endpoint’s logs; after remediation, the second hostname should not receive the original `Authorization: Bearer` header. Also verify `.netrc` files do not contain broad `default` entries unless they are explicitly required and risk-accepted.

Typical attack path

1. Identify or influence a workflow that uses curl/libcurl with an OAuth2 bearer token, redirect following, and .netrc processing.
2. Cause the authenticated request to receive an HTTP redirect to an attacker-controlled or observable second hostname.
3. Ensure the redirected hostname matches a `.netrc` `machine` entry, or rely on a `.netrc` `default` entry if present.
4. Receive the redirected request and capture the unintended `Authorization: Bearer` header.
5. Replay the exposed bearer token against the intended API or service until the token expires or is revoked.
6. Use the token’s granted permissions to read data or perform API actions within its scope.

How to detect it

Evidence of exploitation is most likely to appear in HTTP proxy logs, egress gateway logs, web server access logs on redirected destinations, application debug logs, curl verbose output, CI/CD job logs, or packet captures from controlled networks. Look for authenticated curl/libcurl requests that receive HTTP 3xx responses and are immediately followed by requests to a different hostname carrying the same `Authorization: Bearer` header. Pay special attention to workflows that use `.netrc`, contain `.netrc` `default` entries, or invoke curl with redirect-following options. Because bearer tokens are usually sent inside TLS, many network devices will only show the destination host and redirect pattern, not the header value, unless TLS inspection, endpoint telemetry, application logging, or destination server logs are available. If a suspicious leak is found, treat the token as compromised, revoke or rotate it, and review downstream API activity performed with that token after the suspected redirect time.

• Authorization: Bearer
• HTTP/1.1 301
• HTTP/1.1 302
• HTTP/1.1 303
• HTTP/1.1 307
• HTTP/1.1 308
• Location:
• .netrc
• _netrc
• default
• machine
• --oauth2-bearer
• --location
• --netrc
• --netrc-optional
• CURLOPT_XOAUTH2_BEARER
• CURLOPT_FOLLOWLOCATION
• CURLOPT_NETRC

What your security team should do

• Prioritize identifying automation, CI/CD, service integrations, and scripts that use curl/libcurl with bearer tokens and redirect following.
• Patch curl/libcurl through OS, container, appliance, and application dependency channels once fixed packages are released by the applicable vendor.
• Temporarily disable cross-host redirects for authenticated curl requests where feasible, or manually validate redirect targets before sending credentials.
• Search repositories, build scripts, container images, and runtime configurations for risky combinations such as `--location`, `--oauth2-bearer`, and `--netrc`.
• Remove unnecessary `.netrc` `default` entries and limit `.netrc` machine entries to trusted hosts.
• Rotate bearer tokens that may have been used in vulnerable workflows, especially tokens with broad permissions or long lifetimes.
• Reduce token blast radius by using short-lived, audience-restricted, least-privilege OAuth tokens.
• Review proxy, egress, and destination server logs for bearer tokens sent to unexpected hosts after HTTP 3xx redirects.
• Add regression tests for applications using libcurl to ensure authorization headers are not forwarded across host boundaries during redirects.