CVE-2026-6429

What it actually does

This flaw is a credential exposure issue in libcurl/curl redirect handling. When an application or command-line invocation is configured to read credentials from a .netrc file and also follows HTTP redirects, libcurl can under certain conditions send the password associated with the original host to the redirected destination host. The attacker does not gain code execution or alter data directly, but may receive sensitive authentication material intended for another service. The CVSS reflects high confidentiality impact, network reachability, high attack complexity, and the need for the victim-side curl/libcurl use case to already involve .netrc credentials and redirect following.

Why it matters to the business

If exploited, credentials used by automation, scripts, integrations, build systems, or operational tooling could be disclosed to an unintended server. This can lead to unauthorized access to APIs, repositories, internal services, or third-party platforms depending on what the leaked .netrc password can access. Operational risk is highest where curl/libcurl is embedded in automated workflows that follow redirects to external or attacker-influenced URLs. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS at the time of assessment, but credential leakage can still create significant downstream compromise if exposed secrets are privileged or reused.

How an attack unfolds

An attacker needs to influence a request made by curl or an application using libcurl so that it uses a .netrc file for credentials and is configured to follow HTTP redirects. The initial request is made to a host for which credentials exist in the .netrc file. The attacker then causes or controls an HTTP redirect to a different host they control or can observe. Under the vulnerable redirect-handling conditions, libcurl may include the password from the original host when connecting to the redirected host. The attacker captures the leaked credential from inbound HTTP authorization material, server logs, reverse proxy logs, or packet capture, then attempts to reuse it against the original service or any other service where the credential is valid.

How to fix it

Upgrade curl/libcurl to a vendor-fixed release as soon as fixed packages are available from the operating system, appliance, container base image, language runtime, or application vendor. Because no exact fixed versions were provided in the input, use the latest security release from the relevant distribution or haxx curl upstream and verify that vendor advisories explicitly include a fix for CVE-2026-6429. Rebuild and redeploy statically linked applications and containers that bundle libcurl, not just the system curl binary. As mitigations, avoid combining .netrc credential use with automatic redirect following for untrusted URLs, disable redirect following where not required, restrict redirects to trusted protocols and hosts where supported, avoid storing high-value long-lived passwords in .netrc, and replace reusable passwords with scoped, short-lived tokens. Rotate any credentials that may have been used by vulnerable curl/libcurl workflows against redirectable or attacker-influenced endpoints.

How to confirm the fix worked

Confirm installed curl and libcurl package versions against the security advisory from the operating system or application vendor. Check both the curl command-line binary and any applications that dynamically or statically link libcurl. On Linux and Unix-like systems, inventory package versions with the native package manager and identify linked libraries with tools such as ldd, otool, or equivalent software composition analysis. Review scripts, CI/CD jobs, service configurations, and application code for use of .netrc together with redirect following, including curl -n/--netrc/--netrc-file combined with -L/--location or libcurl options such as CURLOPT_NETRC and CURLOPT_FOLLOWLOCATION. After remediation, run a controlled test using a .netrc credential and redirect to a test-controlled host to verify that credentials intended for the first host are not sent to the redirected host. Also verify that containers and embedded appliances have been rebuilt or patched rather than only updating the host operating system.

Typical attack path

1. Identify or create a workflow that invokes curl/libcurl with .netrc credential loading enabled.
2. Ensure the same workflow follows HTTP redirects, such as with curl -L or equivalent libcurl options.
3. Cause the initial request to receive an HTTP redirect to an attacker-controlled or attacker-observable host.
4. Receive the redirected request and capture any leaked credential intended for the original host.
5. Reuse the exposed credential against the original host, related APIs, source repositories, artifact stores, or other services if password reuse exists.

How to detect it

To determine whether exploitation may already have occurred, focus on places where curl/libcurl is used with .netrc credentials and redirect following. Review shell histories, scheduled jobs, CI/CD logs, application logs, proxy logs, and egress web gateway logs for curl invocations using --netrc, --netrc-file, or -n together with --location or -L. Inspect outbound HTTP traffic records for requests that followed 3xx redirects from trusted credentialed hosts to unexpected domains or IP addresses. On servers controlled by the organization, review access logs for Authorization headers or authentication failures immediately after redirects involving curl user agents. For suspected attacker-controlled destinations, look for outbound connections from automation hosts to unusual domains shortly after requests to legitimate credentialed services. Investigate any leaked credential by reviewing downstream authentication logs on the service the .netrc entry was intended for, looking for new source IPs, unusual user agents, unexpected API calls, token creation, repository access, artifact downloads, or privilege changes after the suspected leak time. Because this is a credential disclosure bug rather than malware, durable host artifacts may be minimal; logs of redirect chains and credential reuse are the most important evidence.

• curl -L
• curl --location
• curl -n
• curl --netrc
• curl --netrc-file
• .netrc
• CURLOPT_FOLLOWLOCATION
• CURLOPT_NETRC
• CURLOPT_NETRC_FILE
• HTTP/1.1 301
• HTTP/1.1 302
• HTTP/1.1 303
• HTTP/1.1 307
• HTTP/1.1 308
• Authorization: Basic
• User-Agent: curl/
• Location: http://
• Location: https://

What your security team should do

• Prioritize inventory of curl/libcurl usage in automation, CI/CD, integration scripts, containers, and products that access sensitive services using .netrc files.
• Patch curl/libcurl through vendor-supported security updates and rebuild statically linked binaries and container images that include vulnerable libcurl code.
• Search code and job configurations for .netrc usage combined with redirect following and remove that pattern wherever possible.
• Temporarily disable automatic redirects for credentialed requests to untrusted or user-controlled URLs until patched.
• Rotate credentials stored in .netrc files that may have been used in vulnerable workflows, especially tokens with repository, artifact, cloud, or production API access.
• Reduce future impact by replacing long-lived passwords with scoped tokens, short-lived credentials, and host-specific authentication policies.
• Monitor outbound HTTP requests and web server logs for credential-bearing requests to unexpected redirected destinations.