Path Traversal in GuzzleHTTP PSR-7

Compliance Impact

The vulnerability in guzzlehttp/psr7 involves improper validation of URI host components, which can lead to discrepancies between the host returned by Uri::getHost() and the actual URI authority. This can cause security decisions based on incorrect host information, potentially allowing unauthorized access, host-based access-control bypass, server-side request forgery (SSRF), or unintended routing.

Such security risks may impact compliance with standards and regulations like GDPR or HIPAA, which require protection of sensitive data and prevention of unauthorized access. If an application relies on this library for security checks or routing decisions involving untrusted input, the vulnerability could lead to data exposure or manipulation, thereby affecting regulatory compliance.

Mitigation involves updating to version 2.12.3 or later, which enforces stricter URI host validation, and validating/normalizing host values before use. Failure to address this vulnerability could increase the risk of non-compliance due to potential data breaches or unauthorized data access.

Useful 0 Not Useful 0

Executive Summary

The vulnerability in guzzlehttp/psr7 involves improper validation of the URI host component in the PSR-7 HTTP message library for PHP. Before version 2.12.3, the method Uri::assertValidHost() did not reject URI host components containing authority delimiters, embedded ports, or malformed IPv6 brackets. This caused the Uri::getHost() method to return a host value that could disagree with the actual URI authority used for security or routing decisions.

This discrepancy can be exploited by attackers to manipulate host values, potentially leading to security risks such as unauthorized access or data manipulation. The issue was fixed in version 2.12.3 by adding stricter validation to ensure that the host extracted by getHost() matches the URI authority exactly.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can impact applications that rely on the Uri::getHost() method for security decisions, such as allowlisting, server-side request forgery (SSRF) protection, or routing based on the host component of a URI.

• Host-based access-control bypass
• Server-side request forgery (SSRF)
• Unintended routing or Host header confusion

Applications processing attacker-controlled host data in URIs or handling untrusted raw HTTP messages are particularly at risk. Additionally, users of guzzlehttp/guzzle are affected because it depends on PSR-7 for deriving Host headers, cookie scopes, and proxy-bypass decisions.

The vulnerability has a moderate CVSS score of 4.2, indicating a network attack vector with high complexity, no privileges required, and user interaction needed.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability involves improper validation of URI host components in the guzzlehttp/psr7 library, which can lead to discrepancies between the host returned by Uri::getHost() and the actual URI authority. Detection involves identifying if your application uses vulnerable versions of guzzlehttp/psr7 prior to 2.12.3 and if it processes untrusted or attacker-controlled URI inputs.

Since the issue is related to URI host parsing, detection on your system can include checking for suspicious or malformed URI host components containing authority delimiters such as /, ?, #, @, \, embedded ports (e.g., host:8080), or malformed IPv6 brackets (e.g., [::1 or ::1]).

There are no specific commands provided in the resources, but you can audit your PHP dependencies to check the installed version of guzzlehttp/psr7 using Composer:

• composer show guzzlehttp/psr7

To detect potential exploitation attempts, you can monitor logs or network traffic for requests containing suspicious URI hosts with embedded delimiters or malformed IPv6 brackets.

Useful 0 Not Useful 0

Mitigation Strategies

The primary mitigation step is to upgrade guzzlehttp/psr7 to version 2.12.3 or later, where the vulnerability is fixed by stricter validation of URI host components.

If upgrading immediately is not possible, as a workaround, you should validate and normalize host values before constructing URIs from untrusted input and avoid relying solely on Uri::getHost() for security decisions.

Additionally, review your application’s use of Uri::getHost() in security-sensitive contexts such as allowlisting, SSRF protection, or routing decisions to ensure it is not vulnerable to host confusion attacks.

Useful 0 Not Useful 0