CVE-2026-67354 in Guzzle
Summary
by MITRE • 08/01/2026
guzzlehttp/guzzle versions before 7.15.1 contain an information disclosure vulnerability in RedirectMiddleware. When the optional allow_redirects.referer setting is enabled, the middleware copies the URI fragment (the portion after '#') from the referring request into the generated Referer header when following a same-scheme redirect (e.g., HTTPS to HTTPS). An attacker who controls the redirect destination can read this fragment from the incoming Referer header, potentially disclosing one-time login secrets, access tokens, state values, or other sensitive client data to a server never meant to receive it. The referer setting is disabled by default. Fixed in 7.15.1, which strips the fragment before generating the Referer value.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/01/2026
The vulnerability exists within the Guzzle HTTP client library's RedirectMiddleware component affecting versions prior to 7.15.1. This information disclosure flaw specifically manifests when the optional allow_redirects.referer configuration parameter is enabled, creating a security risk that allows sensitive data to be inadvertently exposed during HTTP redirect operations. The issue stems from how the middleware handles URI fragments during same-scheme redirects, where it incorrectly preserves and propagates these fragment components from the original request into subsequent Referer headers.
The technical implementation of this vulnerability occurs through the redirect middleware's processing logic that fails to sanitize URI fragments before constructing the Referer header value. When a client makes an HTTP request with a URL containing a fragment identifier and the redirect functionality is enabled, the middleware copies the entire URI including its fragment component into the Referer header sent with the redirected request. This behavior becomes particularly dangerous when the redirect target is controlled by an attacker who can observe incoming HTTP requests and extract sensitive information from the Referer header.
The operational impact of this vulnerability extends beyond simple information disclosure to potentially compromise authentication mechanisms and session management systems. Attackers can exploit this flaw to harvest one-time login secrets, access tokens, state parameters, and other sensitive client-side data that might be embedded within URI fragments. These fragments often contain critical security tokens or session identifiers that should remain confidential between the client and its intended server endpoints. The vulnerability particularly affects applications that rely on fragment-based authentication flows or use fragments to store temporary credentials during OAuth or similar authorization processes.
This security weakness aligns with CWE-201, Information Exposure Through Sent Data, and can be mapped to ATT&CK technique T1566.001 for credential access through the exploitation of information disclosure vulnerabilities. The vulnerability demonstrates a classic case of improper input validation where URI components are not properly sanitized during HTTP processing operations. The fix implemented in version 7.15.1 addresses this by stripping fragment identifiers from URIs before generating Referer header values, ensuring that sensitive data cannot be inadvertently transmitted to unintended recipients.
The default configuration status of the referer setting provides some mitigation but does not eliminate the risk entirely, as developers may explicitly enable this functionality for legitimate use cases while unknowingly introducing security vulnerabilities. Organizations using Guzzle HTTP client libraries should prioritize updating to version 7.15.1 or later to resolve this information disclosure vulnerability, particularly those handling sensitive authentication data or operating in environments where redirect destinations might be controlled by malicious actors. The mitigation strategy focuses on proper URI component sanitization and ensuring that fragment identifiers are never transmitted in Referer headers unless explicitly required for legitimate cross-domain tracking purposes.