CVE-2024-2756

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.

A Security Bypass vulnerability (CVE-2024-2756) has been identified in the way PHP turns cookie names into $_COOKIE keys, which allows a network or same-site attacker to set an ordinary cookie in a victim's browser that PHP applications then treat as a __Host- or __Secure- cookie. It exists because the fix for CVE-2022-31629 was incomplete. PHP tracks this issue as GHSA-wpj3-hf5j-x4v4.

Per MITRE CWE-20: The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

This issue affects all versions of PHP before 8.1.28, PHP 8.2 before 8.2.18 and PHP 8.3 before 8.3.5.

Details

Module Info

• Product: PHP
• Affected packages: php-src (main/php_variables.c)
• Affected versions: <8.1.28, >=8.2.0 <8.2.18, >=8.3.0 <8.3.5
• 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.28, 8.2.18, 8.3.5
  • 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 request variable registration of all PHP versions before 8.1.28, PHP 8.2 before 8.2.18 and 8.3 before 8.3.5, including the End-of-Life PHP 5.6, 7.0, 7.1, 7.2, 7.3, 7.4 and 8.0 release lines, which never received the upstream fix. The PHP project scores it 6.5 under CVSS 3.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N).

Browsers accept a cookie whose name starts with __Secure- only if it was set with the Secure flag from an HTTPS page, and a __Host- cookie only if it was also set without a Domain attribute and with the path /. Applications rely on these prefixes to know a cookie came from their own origin over HTTPS. PHP, however, rewrites variable names before it stores them: spaces and dots become underscores, and a [ without a matching ] also becomes an underscore. CVE-2022-31629 showed that this mangling can turn an ordinary cookie name into one with a protected prefix, and its fix added a check that drops such names. In PHP 7.4.33 the check reads:

/* Discard variable if mangling made it start with __Host-, where pre-mangling it did not start with __Host- */
if (strncmp(var, "__Host-", sizeof("__Host-")-1) == 0 && strncmp(var_name, "__Host-", sizeof("__Host-")-1) != 0) {
    zval_ptr_dtor_nogc(val);
    free_alloca(var_orig, use_heap);
    return;
}

The check runs right after spaces and dots are replaced, but before PHP handles brackets. Later in the same function, an unmatched [ is replaced with an underscore. A cookie named .[Host-test or _[Secure-test therefore passes the check and is then stored as $_COOKIE['__Host-test'] or $_COOKIE['__Secure-test']. The browser applies no prefix rules to these names, so a sibling subdomain or a plain-HTTP response can set them.

Exploitation needs an application that trusts __Host- or __Secure- cookies, for example for session or CSRF tokens, and an attacker who can set cookies for the victim's domain from the network or a same-site origin. The victim's browser must then visit the application. The issue affects any SAPI that registers request variables (PHP-FPM, CGI, the Apache module and the CLI built-in server). Applications that do not rely on these prefixes are not affected.

The fix moves the check to the point where the final name is known, right before the variable is added, so names produced by bracket mangling are dropped as well. In PHP 8.1.28 each of those points calls a new helper, php_is_forbidden_variable_name(), which applies the same __Host- and __Secure- tests to the final name. PHP 5.6 and 7.2 never received the CVE-2022-31629 check upstream, so the NES releases for those lines carry both fixes, with the check applied to the final name:

if (php_is_forbidden_variable_name(index, index_len, var_name)) {
    zval_ptr_dtor_nogc(val);
    free_alloca(var_orig, use_heap);
    return;
}

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.28, 8.2.18, 8.3.5, or later.
• Leverage a commercial support partner like HeroDevs (NES for PHP) for post-EOL security support.

Credits

• Marco Squarcina (finder)
• Nora Dossche (remediation)