curl leaks OAuth bearer tokens on redirects when using .netrc

TL;DR - curl can hand an OAuth bearer token to the wrong host on redirect. Specifically, when the redirect target matches a .netrc entry.

What happened

curl is the command-line tool and library you cannot escape - embedded in countless apps and CI pipelines via libcurl. CVE-2026-3783 covers an edge case where, after an HTTP redirect, an OAuth2 bearer token can end up in the request to the redirected host. The trigger: that hostname matches a machine or default entry in the user's .netrc.

curl rates it Medium. That feels light. Bearer tokens are everywhere in CI automation, service-to-service calls, and scripts - and .netrc plus redirects is a common combination. Operational impact tends to outrun the CVSS here.

Affected versions span 7.33.0 through 8.18.0. Roughly a decade of releases.

Who is impacted

• curl/libcurl 7.33.0 through 8.18.0 (inclusive).
• Any environment using curl with OAuth2 bearer tokens, redirects enabled, and a .netrc file that can match the redirected hostname.
• libcurl is often embedded indirectly - check transitive dependencies.

What to do now

• Follow vendor remediation guidance and apply the latest patched release available at the time of writing.
• If you cannot patch, reduce exposure by avoiding the combination of bearer tokens + redirects, and review/limit .netrc use (especially default) in automation.
• Inventory where libcurl is embedded and prioritize updates in internet-facing or CI/CD environments.