CVE-2026-67339: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-67339 is a credential disclosure vulnerability in guzzlehttp/guzzle (the Guzzle PHP HTTP client) where Proxy-Authorization headers are improperly sent to origin servers instead of being restricted to the proxy. All versions before 7.14.2 are affected. The vulnerability was published on August 1, 2026, with a patch available in version 7.14.2. It carries a CVSS v3.1 score of 5.3 (Medium) and a CVSS v4.0 score of 6.9 (Medium) (GitHub Advisory, Feedly).

The root cause (CWE-200, CWE-201, CWE-522) lies in how Guzzle's built-in cURL handlers (CurlHandler and CurlMultiHandler) manage the Proxy-Authorization header. These handlers place all first-class request headers into cURL's origin header list (CURLOPT_HTTPHEADER) and only migrate Proxy-Authorization to the proxy-only list (CURLOPT_PROXYHEADER) when Guzzle predicts an HTTP/HTTPS proxy — a prediction that can be wrong. The credential leaks to the origin server in four scenarios: (1) direct requests or those with proxying disabled, (2) requests bypassed by no_proxy rules, (3) requests routed through SOCKS proxies (which don't use the HTTP proxy header channel), and (4) redirects from a proxied hop into any of those routes, since redirect middleware re-evaluates the proxy per hop but does not strip Proxy-Authorization cross-origin. On libcurl versions older than 7.37.0 or PHP builds lacking CURLOPT_PROXYHEADER/CURLHEADER_SEPARATE, no proxy-only channel exists at all, making every route vulnerable. The stream handler had a parallel flaw where it serialized first-class header values before selecting a proxy route (GitHub Advisory).

Successful exploitation results in the disclosure of proxy authentication credentials (Proxy-Authorization header values) to unintended origin servers. An attacker who controls or has access to an origin server can harvest these credentials from access logs, tracing systems, or application logs. With a captured credential, an attacker could abuse a paid or access-controlled proxy, impersonate the proxy principal, or reach destinations the proxy is trusted to access. The impact is limited to confidentiality — there is no integrity or availability impact — but the credential exposure can enable significant secondary attacks (GitHub Advisory, Feedly).

1. Identify a target application: Find a PHP application using guzzlehttp/guzzle < 7.14.2 that configures a Proxy-Authorization header as a first-class header (e.g., via client defaults or middleware) and follows HTTP redirects.
2. Control or monitor an origin server: Set up or gain access to an HTTP server that the target application can be induced to contact, with access to its request logs or tracing systems.
3. Trigger a redirect: Serve an HTTP response from the attacker-controlled origin that redirects the Guzzle client to an HTTPS URL, a no-proxy destination, or a SOCKS-proxied route — any route where Guzzle will not migrate the Proxy-Authorization header to the proxy-only channel.
4. Capture the credential: When Guzzle follows the redirect, it sends the Proxy-Authorization header directly to the destination origin server. Inspect the origin server's access logs or request headers to extract the proxy credential.
5. Abuse the credential: Use the captured proxy credential to authenticate to the proxy, potentially accessing restricted destinations, impersonating the proxy principal, or consuming paid proxy resources (GitHub Advisory).

• Network: Outbound HTTP/HTTPS requests from a Guzzle-based application to unexpected or attacker-controlled origin servers containing a Proxy-Authorization header in the request (observable via network inspection or proxy logs).
• Logs: Origin server access logs or application tracing systems showing inbound requests with a Proxy-Authorization header from Guzzle clients; this header should never appear in origin server logs under normal operation.
• Application: Unexpected redirect chains in Guzzle request logs, particularly redirects from HTTP to HTTPS or to destinations matching no_proxy rules, which may indicate an attacker is engineering the credential leak.

Upgrade guzzlehttp/guzzle to version 7.14.2 or later, which fixes the cURL handlers to keep first-class Proxy-Authorization values out of the origin header list and properly routes them via CURLOPT_PROXYHEADER with CURLHEADER_SEPARATE where available. If an immediate upgrade is not possible, remove first-class Proxy-Authorization headers from requests, client defaults, and middleware, and supply proxy credentials instead through proxy URL userinfo (e.g., http://user:pass@proxy.example:8080) or via CURLOPT_PROXYUSERPWD. After patching, review origin server access logs for historical exposure and consider rotating proxy credentials if leakage is suspected (GitHub Advisory, Feedly).

The advisory was authored and published by GrahamCampbell, a prominent Guzzle maintainer, on July 14, 2026, with the CVE assigned on August 1, 2026. The disclosure includes a detailed technical write-up covering all affected code paths, which reflects a thorough coordinated disclosure process. No significant broader media coverage or notable community controversy has been observed at this time (GitHub Advisory).