CVE-2026-9079: 
cURL vulnerability analysis and mitigation

CVE-2026-9079 is a stale proxy password leak vulnerability in libcurl that causes the library to fail to clear proxy authentication credentials when explicitly instructed to do so, leaving old credentials in memory to be reused in subsequent transfers that should not have access to them. It affects curl/libcurl versions 8.8.0 through 8.20.0 (inclusive), and was introduced by commit d5e83eb745762f48d8fafadc5df5dd3ae8d8941e. The vulnerability was reported to the curl project on May 20, 2026, by the XlabAI Team of Tencent Xuanwu Lab, and publicly disclosed on June 24, 2026, coordinated with the release of curl 8.21.0. The curl project rates this as Medium severity, while the NVD/GitHub Advisory Database assigns a CVSS v3.1 score of 9.8 (Critical) (curl Advisory, Github Advisory).

The root cause is classified under CWE-522 (Insufficiently Protected Credentials) and CWE-212 (Improper Removal of Sensitive Information Before Storage or Transfer). When an application using libcurl calls the API to clear proxy credentials (e.g., setting CURLOPT_PROXYUSERPWD to NULL or empty between transfers on a reused handle), libcurl fails to actually wipe the stored credentials, leaving them active in the internal handle state. Subsequent transfers using the same handle then inadvertently send the stale Proxy-Authorization header to proxies or destinations that should not receive those credentials. The flaw is specific to libcurl's library API and does not affect the curl command-line tool (curl Advisory, curl JSON). A public proof-of-concept (poc-proxyuserpwd-stale.c) with a Docker environment demonstrates the bug by capturing leaked Proxy-Authorization headers (HackerOne PoC).

Exploitation allows stale proxy authentication credentials to be sent to unintended destinations during subsequent HTTP transfers, resulting in unauthorized access to proxy-protected resources or services. The primary impact is confidentiality — proxy credentials (username and password) are disclosed to parties that should not receive them, potentially enabling an attacker or a malicious proxy to authenticate as the victim application. In multi-tenant or shared proxy environments, this could facilitate lateral movement or access to sensitive backend systems protected by proxy authentication (curl Advisory, Github Advisory, Red Hat Bugzilla).

1. Identify vulnerable applications: Locate applications that use libcurl versions 8.8.0–8.20.0 via the library API (not the curl CLI), particularly those that reuse curl handles across multiple transfers with different proxy configurations.
2. Set up a malicious or monitoring proxy: Position a proxy server capable of capturing Proxy-Authorization headers between the vulnerable libcurl client and its intended destination.
3. Trigger credential clearing: Cause the target application to attempt to clear proxy credentials between transfers (e.g., by switching proxy targets or calling the credential-clearing API), which libcurl silently fails to execute.
4. Capture stale credentials: Observe the subsequent transfer — libcurl sends the old Proxy-Authorization header (e.g., attacker:secret) to the new destination or proxy, where it can be intercepted and captured.
5. Reuse captured credentials: Use the harvested proxy credentials to authenticate to proxy-protected resources or services the attacker should not have access to (HackerOne PoC, curl Advisory).

• Network: Unexpected Proxy-Authorization headers appearing in HTTP requests to destinations or proxies that should not require proxy authentication; repeated proxy authentication attempts from a single client across different target hosts.
• Logs: Application or proxy access logs showing Proxy-Authorization headers sent during transfers where proxy credentials were explicitly cleared by the application; authentication successes at proxy servers for sessions that should be unauthenticated.
• Process/Application: libcurl-based applications exhibiting unexpected proxy authentication behavior after credential rotation or handle reuse; debug output (via CURLOPT_VERBOSE) showing Proxy-Authorization headers in requests where none should be present (HackerOne PoC, curl Advisory).

The primary remediation is to upgrade curl/libcurl to version 8.21.0 or later, which contains the fix in commit 88c7e16cceec816a2df45c899d49b1e85513f193. As a workaround for those unable to upgrade immediately, the curl project recommends avoiding reuse of curl handles when changing proxy credentials — create a new handle instead. Applying the upstream patch and rebuilding is also an option. Organizations should audit applications using libcurl 8.8.0–8.20.0 that reuse handles with proxy credential changes (curl Advisory, Github Advisory).

The curl 8.21.0 release, which patched 18 security vulnerabilities including CVE-2026-9079, received notable media coverage. Several outlets highlighted the release as patching a "25-year-old vulnerability" in curl, used by an estimated 30 billion devices, though this characterization appears to refer to the broader curl codebase rather than this specific CVE (introduced in 8.8.0). Coverage appeared on CyberSecurityNews, Cryptika, VPNcentral, and others (CyberSecurityNews, VPNcentral). Daniel Stenberg, curl's lead developer, published a release blog post announcing the fixes (Daniel Stenberg Blog). Red Hat opened a high-severity tracking bug for the issue, indicating downstream Linux distribution patching activity (Red Hat Bugzilla).