CVE-2024-11234

Overview

PHP is a general-purpose scripting language used mostly for web development. It runs behind web servers through server APIs such as Apache mod_php and PHP-FPM, and powers content management systems and frameworks such as WordPress, Drupal, Moodle and Laravel. Its HTTP stream wrapper lets functions such as file_get_contents() and fopen() fetch URLs, optionally through an HTTP proxy configured in a stream context.

A Server-Side Request Forgery (SSRF) vulnerability (CVE-2024-11234) has been identified in the HTTP stream wrapper of PHP's standard library, which allows an attacker who controls part of a URL that an application fetches through a proxy with the request_fulluri option to inject carriage returns and line feeds into the request, adding headers or whole requests sent through the proxy. PHP tracks this issue as GHSA-c5f2-jwm7-mmq2.

Per MITRE CWE-918: The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

This issue affects all versions of PHP before 8.1.31, PHP 8.2 before 8.2.26 and PHP 8.3 before 8.3.14, including the End-of-Life release lines PHP 5.6, 7.0, 7.1, 7.2, 7.3, 7.4 and 8.0 through their final releases.

Details

Module Info

• Product: PHP
• Affected packages: php-src (ext/standard)
• Affected versions: <8.1.31, >=8.2.0 <8.2.26, >=8.3.0 <8.3.14
• GitHub repository: https://github.com/php/php-src
• Published packages: https://www.php.net/downloads
• Package manager: N/A
• Fixed in:
  • OSS PHP 8.1.31, 8.2.26, 8.3.14
  • NES for PHP 5.6.1 (based on PHP 5.6.40)
  • NES for PHP 7.2.1 (based on PHP 7.2.34)
  • NES for PHP 7.4.1 (based on PHP 7.4.33)

Vulnerability Info

This Medium-severity vulnerability is found in the HTTP stream wrapper of PHP before 8.1.31, 8.2 before 8.2.26 and 8.3 before 8.3.14. The CVE record does not list the End-of-Life PHP 5.6, 7.0, 7.1, 7.2, 7.3, 7.4 and 8.0 release lines, but they carry the same code and never received the upstream fix. The PHP project scores it 4.8 under CVSS 3.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).

When a stream context sets the proxy option, PHP connects to the proxy and sends it the HTTP request. With the request_fulluri option, PHP writes the full URL into the request line instead of only the path and query, which is what many proxies expect. The advisory explains that this path skips the control character sanitization that the normal path receives, so the URL is written into the request as given. Setting a proxy for an ftp:// stream turns on request_fulluri automatically.

If the URL contains carriage return and line feed characters from user input, they end the request line early, and the rest of the URL is read by the proxy as additional headers or as a second request. The advisory describes the consequences as HTTP request smuggling: an attacker can make the server send arbitrary requests through the proxy, reach internal endpoints that only the proxy can access, control the Host header, and set headers such as Authorization or Cookie. In some setups the attacker may also read the responses to the smuggled requests.

Exploitation needs an application that fetches a URL the attacker influences through file_get_contents(), fopen() or a similar function, with allow_url_fopen enabled and a stream context that sets proxy together with request_fulluri, or sets proxy on an FTP stream. This applies to any SAPI. Applications that do not use a proxy in their stream contexts are not exposed.

The fix refuses such a URL before the connection is opened. In the upstream code it reads:

if (request_fulluri && (strchr(path, '\n') != NULL || strchr(path, '\r') != NULL)) {
    php_stream_wrapper_log_error(wrapper, options, "HTTP wrapper full URI path does not allow CR or LF characters");
    php_url_free(resource);
    zend_string_release(transport_string);
    return NULL;
}

Mitigation

The PHP project publishes security fixes only for its supported release lines. PHP 5.6, 7.0, 7.1, 7.2, 7.3, 7.4 and 8.0 are End-of-Life and will not receive any public updates to address this issue.

Users of the affected components should apply one of the following mitigations:

• Upgrade to PHP 8.1.31, 8.2.26, 8.3.14, or later.
• Leverage a commercial support partner like HeroDevs (NES for PHP) for post-EOL security support.

Credits

• Lorenzo Leonardini (finder)
• Jakub Zelenka (remediation)