CVE-2026-55568: Guzzle HTTPS Proxy Cleartext Credential Exposure

Technical summary

Guzzle's CurlHandler and CurlMultiHandler, the default HTTP handlers when PHP's cURL extension is available, accept https:// proxy URIs. When libcurl versions older than 7.50.2 process these URIs, they treat the https:// scheme as plaintext http:// without establishing TLS to the proxy server or generating warnings. As a result, Proxy-Authorization headers, proxy credentials embedded in the proxy URL, CURLOPT_PROXYUSERPWD configuration, and CONNECT tunnel target hostnames and ports transit the proxy hop in cleartext. An attacker positioned to observe network traffic between the application and proxy can harvest authentication credentials and surveillance connection patterns. The vulnerability stems from a silent protocol downgrade rather than explicit mishandling of encryption parameters.

Business impact

For organizations relying on HTTPS proxies as a security boundary (e.g., to enforce inspection, filtering, or credential isolation), this vulnerability undermines that control. Exposed proxy credentials could allow attackers to assume the application's proxy identity, bypass policies, or pivot to other services. Sensitive metadata about which hosts and ports are being accessed leaks to network observers. The practical impact depends on the composition of the technology stack: applications still running against older libcurl versions face immediate risk, while those on current libcurl are already protected—but may not realize their configuration assumptions were silently violated by older library versions.

Affected systems

Guzzle versions prior to 7.12.1 are affected when deployed in an environment where: (1) the PHP cURL extension is in use (standard default), (2) an https:// proxy is configured, and (3) the underlying libcurl library is older than version 7.50.2. Typically, libcurl 7.50.2 was released in 2016; applications on modern Linux distributions, macOS, or Windows with current system package managers generally have a patched libcurl. Legacy systems, containers with pinned older images, or developers running outdated development environments remain at risk.

Exploitability

Exploitation requires network-level access to observe traffic between the application and its proxy—a capability available to network administrators, compromised infrastructure, or attackers on shared networks. No authentication, user interaction, or special application logic is required; the flaw is automatic and silent. The barrier to exploitation is ambient network presence rather than technical sophistication. An attacker does not need to inject or manipulate packets; passive observation suffices. Attacks are difficult to detect because the application and proxy may appear to operate normally while credentials leak.

Remediation

Upgrade Guzzle to version 7.12.1 or later. Additionally, verify that the underlying libcurl library is at version 7.50.2 or later (check via 'curl --version' or curl_version() in PHP). If libcurl cannot be updated immediately, disable https:// proxy configurations and switch to plaintext http:// URIs if the proxy itself is on a trusted network, or do not use a proxy until libcurl is updated. Consider also reviewing proxy credential storage to ensure secrets are not hardcoded in configuration files.

Patch guidance

Apply Guzzle 7.12.1 or any later version from the project's official releases. This patch is expected to include logic that either validates the libcurl version and warns/errors if it is too old, or implements its own TLS proxy connection handling. After updating Guzzle, restart the application to load the new code. Verify the update by checking the version in vendor/guzzlehttp/guzzle/composer.json or by running composer show guzzlehttp/guzzle. Simultaneously, confirm libcurl is at 7.50.2 or later; if on a system package manager, run apt-get upgrade, brew upgrade, or equivalent and restart PHP-FPM or web services.

Detection guidance

Monitor network traffic for Proxy-Authorization headers or proxy credentials in plaintext HTTP streams directed at proxy servers. If an https:// proxy URL is configured in application code or environment variables but libcurl is older than 7.50.2, flag this as a configuration risk. Audit Guzzle version in composer.lock and libcurl version via system package management tools or PHP's phpinfo(). Review web server and application logs for any deprecation warnings or curl errors; older libcurl may silently downgrade but security scanning tools should flag mismatched TLS expectations. Correlate proxy configuration inspection with libcurl version inventory to identify at-risk instances.

Why prioritize this

This vulnerability merits prompt attention because it silently breaks a security assumption (that https:// proxies are encrypted) without warning, and credentials are directly exposed if the configuration is in place. However, the CVSS score of 5.9 reflects the high bar for real-world impact: the flaw requires both an outdated libcurl and an https:// proxy configuration, which is not universal. Organizations using modern infrastructure, or those not relying on HTTPS proxies, face lower practical risk. Prioritize according to your proxy architecture and libcurl inventory; if you do use https:// proxies, patch within days; if not, prioritize within weeks.

Risk score, explained

The CVSS 3.1 score of 5.9 (MEDIUM, AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) reflects high impact on confidentiality (credentials and connection metadata exposed) balanced against a high attack complexity: an attacker must have network access, and the specific configuration (https:// proxy + old libcurl) must be in place. The lack of integrity or availability impact is correct—data is leaked, not corrupted or deleted. The score appropriately penalizes the silent failure mode and the direct nature of credential exposure, while acknowledging that remediation requires both a Guzzle upgrade and a libcurl upgrade, creating a dual barrier to exploitation in fully patched environments.

Frequently asked questions