CVE-2026-3783: Curl Bearer Token Leak via .netrc Redirects Fixed in 8.19.0

A newly disclosed flaw, tracked as CVE-2026-3783, allows an OAuth2 bearer token to be unintentionally forwarded across HTTP(S) redirects when cURL or libcurl is instructed to use credentials from a user .netrc file — potentially exposing sensitive access tokens to attacker-controlled hosts. The issue was confirmed and patched upstream in libcurl version 8.19.0; the vulnerability affects libcurl and curl releases from 7.33.0 through 8.18.0 and is rated Medium severity. This article explains what happened, who is at risk, how the bug works, practical reproduction notes, recommended mitigations, detection and response actions, and the residual risks administrators and developers must treat as urgent.

Background / Overview​

cURL and libcurl are foundational pieces of internet tooling: a command-line HTTP client and an embeddable library used by countless applications, services, and OS distributions. Many automated workflows — CI runners, scripts, cloud agents, and command-line tooling — rely on bearer tokens (Authorization: Bearer) to authenticate API calls. Separately, the .netrc file remains a legacy convenience for storing hostname-specific credentials for tools like curl.
Over the years, netrc-related redirect leaks have recurred in cURL and in other HTTP libraries: prior vulnerabilities demonstrated how credentials from .netrc or other credential stores can be misapplied to redirected hosts under niche conditions. CVE-2026-3783 is the latest instance in that class, this time involving an OAuth2 bearer token, .netrc handling, and the redirect-following logic.
The core issue: when a transfer uses an OAuth2 bearer token and curl follows an HTTP redirect to another host, under specific .netrc configurations curl could apply logic that results in the Authorization: Bearer header being sent to the redirect target. If that redirect target is controlled by an attacker, the token can be captured and reused.

---

How the vulnerability works (technical detail)​

The chain of components​

• OAuth2 bearer token: an opaque or JWT token transmitted in the HTTP Authorization: Bearer <token> header.
• .netrc: a client-side plaintext file that maps hostnames to credentials; it supports machine entries and a default entry that applies broadly.
• Redirect handling: curl can be told to follow redirects (for example, -L / --location), which triggers an internal workflow that decides whether to include authentication headers in subsequent requests.
• Host checks / bypass paths: curl’s internal routines determine whether it is safe to re-send sensitive headers to a new host; previous vulnerabilities and options like CURLOPT_UNRESTRICTED_AUTH illustrate how this decision-making is delicate.

The bug in plain terms​

Under a specific combination:

• The initial request carries a bearer token (provided via --oauth2-bearer or equivalent libcurl option).
• A .netrc file contains an entry for the redirect target host — or a default entry that matches all hosts.
• The server responds with an HTTP redirect to a second URL on that host.
• The redirect-following code path inadvertently bypasses the usual host-allow checks for the bearer token when the .netrc entry is present, causing curl to emit the bearer token to the new host.

In short: .netrc presence caused a bypass in the bearer output path such that the token could be emitted to a host that should not have received it.

What was changed to fix it​

Upstream maintainers added a guard so that bearers are only emitted when the destination host is permitted by the regular host check (i.e., it must pass the same test used to decide whether credentials are allowed to be sent to that host). A minimal code change enforces the host-allow decision for the bearer path, and tests were added to cover the scenario.

---

Affected versions and timeline​

• Affected versions: curl releases from 7.33.0 through and including 8.18.0.
• Fixed in: curl / libcurl 8.19.0 (patch committed and released in coordination with public disclosure).
• Disclosure timeline: the issue was reported, triaged, a patch was implemented and released in 8.19.0, and public advisories were made available by the curl team and major distros shortly after.

Administrators should treat the version range above as the authoritative affected set unless a downstream vendor states otherwise for their repackaged/embedded libcurl.

---

Reproduction (high-level, safe testing steps)​

Security researchers outlined a straightforward proof-of-concept pattern — do not run these against untrusted networks:

• Create a .netrc file with either:
• an explicit machine entry matching the redirect target, or
• a default entry (this is particularly risky because it matches any host).
• Start two simple HTTP endpoints: one that returns a 302/301 Location header to the second host, the other that will receive the redirected request.
• Execute curl with:
• --oauth2-bearer "SOME_TOKEN"
• --netrc-file /path/to/.netrc (or --netrc)
• -L to follow redirects
• Observe that the second server receives an Authorization: Bearer SOME_TOKEN header when it should not.

Researchers also note that the problem is specific to the bearer path combined with .netrc; setting the Authorization header via -H 'Authorization: Bearer ...' follows a separate path that may not be vulnerable in the same way.

---

Who is at risk​

• Any system using a vulnerable libcurl or curl binary where:
• an OAuth2 bearer token is supplied to curl (via --oauth2-bearer or programmatically) and
• the run-time environment supplies a .netrc entry that matches the redirect destination and
• redirects are followed (for example, -L / CURLOPT_FOLLOWLOCATION).

Key practical vectors:

• CI/CD agents and build systems that call protected APIs using curl and store helper credentials in .netrc.
• Automation scripts and cron jobs that follow redirects for API calls and rely on .netrc.
• Applications embedding libcurl where .netrc or programmatic netrc-like behavior is enabled.
• Containers and images built with older libcurl could expose services across environments.
• Potential Windows exposure: modern Windows distributions include curl by default; whether the shipped curl.exe is within the affected range depends on the Windows build and update status. Administrators should explicitly check the bundled version on Windows endpoints.

Not every user is at risk — the exploit requires the specific combination of bearer tokens, .netrc presence, and redirects. But because many automated systems and scripts are run unattended with those exact characteristics, the practical risk is meaningful.

---

Immediate mitigations and remediation steps​

If you cannot immediately upgrade to libcurl / curl 8.19.0, implement one or more of the following mitigations:

• Upgrade: the primary fix is to install curl/libcurl 8.19.0 or a patched vendor package as soon as it is available for your distribution or product. This is the recommended action.
• Avoid the combo: do not use .netrc to drive authentication for requests that carry an OAuth2 bearer token and might follow redirects.
• Disable redirect-following: run curl without -L / --location or disable automatic redirect behavior in libcurl (CURLOPT_FOLLOWLOCATION) when bearer tokens are in play.
• Use explicit headers with host checks: prefer setting Authorization: Bearer <token> explicitly when you can also guarantee the destination host is validated, and avoid blindly trusting redirects.
• Rotate tokens: if you suspect a bearer token may have been exposed (e.g., a script executed with a vulnerable curl against untrusted endpoints), rotate / revoke the token immediately.
• Hardening flags: avoid using options like --location-trusted or CURLOPT_UNRESTRICTED_AUTH unless you fully understand the trust implications; these intentionally relax host-checking.
• For embedders: review how your application uses libcurl and .netrc, and if necessary, instrument the code to block sending Authorization headers to different hosts.

---

Detection and response: what to look for​

Detection can be hard because network captures must be correlated to specific runs of curl or embedded libcurl calls. Suggested steps:

• Audit logs and network traffic for Authorization: Bearer being sent to hosts that differ from the intended API host.
• Search for presence of .netrc files in build agents, container images, and home directories of service accounts.
• Inventory curl/libcurl versions across servers, containers, developer machines, and build agents. If you find versions within the affected range, treat them as vulnerable until patched.
• Inspect CI/CD scripts and scheduled jobs for uses of --netrc, --netrc-file, -L, or programmatic equivalents that combine OAuth2.
• Check application code that embeds libcurl: does it rely on netrc-style credential discovery? If so, add guards or require explicit host allowlists.
• Look for suspicious outbound redirects from internal endpoints (a misconfigured proxy or developer tool that redirects to third-party hosts could be misused).
• If you find any token leaks or suspect exposure, immediately revoke and rotate the affected credentials and perform an incident response investigation to determine scope.

---

Practical checklist for teams (prioritized)​

• Inventory: find all systems that have curl/libcurl versions in the affected range.
• Patch: apply vendor patches or upgrade to curl/libcurl 8.19.0 or later.
• Audit: locate .netrc files and evaluate whether scripts/agents use them with bearer tokens.
• Revoke/Rotate: rotate any potentially exposed tokens and update secrets management to safer practices.
• Harden: update scripts to avoid following redirects when sending bearer tokens; prefer explicit target host validation.
• Monitor: add logging/IDS rules to flag Authorization headers sent to unexpected hosts.
• Communicate: notify application teams, developers, and CI owners about the specific risk and required remediation.

---

Why this matters — real-world scenarios​

• A CI runner using a short-lived bearer token to call a package registry could follow a redirect (legitimately or via malicious injection) and hand the token to a redirect target. An adversary controlling that redirect target can capture and reuse tokens to access internal services.
• Developer laptops that use .netrc for convenience could execute scripts that follow redirects to attacker-controlled domains through DNS hijacking or HTTP redirects, allowing covert exfiltration of tokens.
• Embedded devices or appliances bundling an older libcurl may unintentionally forward credentials during firmware update checks or API calls if a redirect is encountered.
• Third-party packaged applications that vendor their own libcurl may lag in applying the stable fix, leaving downstream customers exposed even after upstream patch release.

---

Why the fix is straightforward — and why risk remains​

The fix upstream was minimal and surgical: adding an additional host-authorization check before emitting the Authorization: Bearer header in the bearer auth path. That simplicity is good news: the patch reduces the probability of regression and is easy to roll into releases.
However, residual risk remains because:

• Many applications embed and statically link libcurl; they will not automatically get the update until vendors rebuild and redistribute.
• Container images, IoT devices, appliances, and old distributions can remain unpatched for months or years.
• The presence of .netrc and convenience-based credential storage remains common; even with the patch, changing developer habits takes time.
• Token rotation and credential hygiene are often not automated in environments that use short-lived tokens, so exposure windows can be long.

Therefore, the patch must be paired with operational changes: secrets management, elimination of .netrc reliance, and improved CI/CD hygiene.

---

Developer guidance: eliminate risky patterns​

• Move away from .netrc for API tokens. Use provider-specific secrets stores, environment variables managed by the orchestrator, or dedicated credential managers with fine-grained access control.
• If your code must follow redirects, explicitly validate the final host and only send tokens to whitelisted domains.
• Add explicit unit and integration tests that assert Authorization headers are not forwarded to different hosts after redirects.
• Bake in secrets scanning and CI policies that forbid storing tokens in .netrc inside repository images or artifacts.
• Rotate keys programmatically on suspected events; integrate token revocation into incident playbooks.

---

For Windows admins: what to check right now​

• Verify the curl version bundled with your Windows build. The presence of a vulnerable libcurl depends on the Windows release and installed updates; consult your patch management. If a bundled curl is within the affected range, plan to update.
• Remember that many Windows-native applications or SDKs might statically link an older libcurl; inventory vendor apps and request security updates from vendors.
• Check WSL, Docker Desktop, and Linux environments on Windows that may contain vulnerable libcurl packages and patch them as part of your overall remediation drive.

(If you need an exact command to inspect a curl binary version locally, use the binary’s version output — but ensure you run it in your environment; the exact version string will confirm vulnerability status.)

---

Risk analysis — strengths and weaknesses of the response​

Strengths:

• The curl maintainers produced a minimal, targeted fix and released it in a maintainer-controlled cycle, which reduces patch complexity.
• The vulnerability is not a universal remote code execution — its impact is information disclosure limited mainly to bearer tokens. That bounds immediate catastrophic risk.
• The issue is easy to reason about and reproduce in controlled environments, which helps operators verify fixes.

Weaknesses and residual risks:

• The pattern of credential leakage via redirects is recurring. Tools and libraries with complex authentication flows continue to have edge cases where credentials may be mishandled.
• Embedded and third-party distributions can lag, creating windows where patched upstream code does not reach end-users.
• Detection of token leakage after the fact can be difficult unless token use is tightly instrumented.
• Operators who rely on .netrc for convenience may be slow to change behavior, keeping attack surface high.

---

Final recommendations​

• Immediate action: prioritize upgrading to curl/libcurl 8.19.0 or later across build agents, servers, and development machines, and ensure vendor products that embed libcurl are patched as vendor updates become available.
• Short-term operational steps: search for .netrc usage in automation and CI, disable automatic redirects when tokens are used, and rotate any tokens you suspect may have been exposed.
• Medium-term posture: stop depending on .netrc for bearer-token workflows; adopt centralized secrets stores and ephemeral tokens with automatic rotation; add automated tests to assert that Authorization headers do not cross host boundaries.
• Detection and monitoring: instrument outgoing HTTP calls, log destinations for Authorization headers, and add alerts for anomalous Authorization transmissions to unexpected hosts.
• Communicate the issue to development teams, security teams, and vendors: the practical hazard comes from fragile combinations of convenience features and redirects, not from raw exploitation complexity. Awareness and rapid patching will neutralize most operational risk.

---

CVE-2026-3783 is another reminder that seemingly minor credential convenience features (.netrc) interacting with complex HTTP behavior (redirects) can yield tangible risks. The fix itself is narrow and available — but the real work is operational: inventory, patching, token hygiene, and changing habits so that credentials are never treated as casually transportable. If your environment uses curl or libcurl in automation, treat this as a priority patch-and-audit task: update to the patched release, hunt for .netrc-driven workflows, and rotate any tokens that may have been exposed.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center