Guzzle HTTP Client CVE-2026-67339

Exploitation requires two co-present conditions: (1) the Guzzle application must set a Proxy-Authorization header as a first-class PSR-7 header (via client 'headers' defaults, the 'headers' request option, or middleware - not through raw CURLOPT_HTTPHEADER/CURLOPT_PROXYHEADER), and (2) at least one of the following routing conditions must apply to that request: the request is sent directly (proxy option set to empty string or absent), the proxy is bypassed because the target matches a no_proxy/NO_PROXY environment variable rule, the configured proxy is a SOCKS proxy (SOCKS4/SOCKS5 do not use the HTTP proxy header channel, so Guzzle never migrates the header), or the request follows a redirect from a proxied hop into any of the above direct routes. On hosts running libcurl older than 7.37.0 or PHP cURL builds lacking CURLOPT_PROXYHEADER/CURLHEADER_SEPARATE support, the header leaks unconditionally on all routes regardless of proxy type. Exploitation is further limited to scenarios where the attacker controls or can observe the origin server receiving the misdirected request (e.g., via access logs, tracing systems, or application logs). No authentication or privilege is required from the attacker's side - the leak is triggered entirely by the victim application's routing behavior.

The CVSS 4.0 base score of 6.9 with vector AV:N/AC:L/AT:N/PR:N/UI:N/VC:L reflects a network-reachable, low-complexity information disclosure - consistent with a credential leakage class finding. However, the official vector's AC:L and AT:N require scrutiny: successful exploitation depends on specific application-side conditions (SOCKS proxy usage, no_proxy bypass, direct-connection mode, or cross-proxy redirects) that are not universally present in default Guzzle deployments. A more conservative independent assessment would raise AC or AT, reducing the score slightly. No EPSS score was provided in the input data and cannot be inferred. KEV status is absent - no confirmed active exploitation. No public proof-of-concept code has been reported. Despite these limiting signals, the real-world risk is meaningful for applications that use Proxy-Authorization credentials over proxied HTTP clients in multi-tier or cloud-egress architectures: the credential leakage is silent, requires no attacker interaction with the victim system, and could provide persistent proxy access. The SSVC exploitation dimension is 'none' based on available data, but technical impact is partial (credential theft enabling secondary abuse). The combination of no KEV, no POC, and condition-dependent triggering suggests this is a genuine but targeted-exposure risk rather than an immediately mass-exploitable critical.

An attacker operates or compromises a web server that serves as an origin endpoint for a PHP application using Guzzle with Proxy-Authorization credentials configured. When the application sends a request that Guzzle routes through a SOCKS proxy - or one that matches a no_proxy rule causing a direct connection - the Proxy-Authorization header appears in the HTTP request received by the attacker's origin server and is recorded in its access log. The attacker then reuses the captured credential to connect through the victim's proxy infrastructure, gaining access to internal or paid-gateway resources the proxy is trusted to reach. No public exploit code has been identified at time of analysis, but the exploitation path requires only standard HTTP server log access.