During DEVCORE’s continuous offensive research, our team discovered a remote code execution vulnerability in PHP. Due to the widespread use of the programming language in the web ecosystem and the ease of exploitability, DEVCORE classified its severity as critical, and promptly reported it to the PHP official team. The official team released a patch on 2024/06/06. Please refer to the timeline for disclosure details.
Description
While implementing PHP, the team did not notice the Best-Fit feature of encoding conversion within the Windows operating system. This oversight allows unauthenticated attackers to bypass the previous protection of CVE-2012-1823 by specific character sequences. Arbitrary code can be executed on remote PHP servers through the argument injection attack.
Impact
This vulnerability affects all versions of PHP installed on the Windows operating system. Please refer to the table below for details:
- PHP 8.3 < 8.3.8
- PHP 8.2 < 8.2.20
- PHP 8.1 < 8.1.29
Since the branch of PHP 8.0, PHP 7, and PHP 5 are End-of-Life, and are no longer maintained anymore, server admins can refer to the Am I Vulnerable section to find temporary patch recommendations in the Mitigation Measure section.
Am I Vulnerable?
For the usual case of combinations like Apache HTTP Server and PHP, server administrators can use the two methods listed in this article to determine whether their servers are vulnerable or not. It’s notable to address that Scenario-2 is also the default configuration for XAMPP for Windows, so all versions of XAMPP installations on Windows are vulnerable by default.
As of this writing, it has been verified that when the Windows is running in the following locales, an unauthorized attacker can directly execute arbitrary code on the remote server:
- Traditional Chinese (Code Page 950)
- Simplified Chinese (Code Page 936)
- Japanese (Code Page 932)
For Windows running in other locales such as English, Korean, and Western European, due to the wide range of PHP usage scenarios, it is currently not possible to completely enumerate and eliminate all potential exploitation scenarios. Therefore, it is recommended that users conduct a comprehensive asset assessment, verify their usage scenarios, and update PHP to the latest version to ensure security.
Scenario 1: Running PHP under CGI mode
When configuring the Action
directive to map corresponding HTTP requests to a PHP-CGI executable binary in Apache HTTP Server, this vulnerability can be exploited directly. Common configurations affected include, but are not limited to:
AddHandler cgi-script .php
Action cgi-script "/cgi-bin/php-cgi.exe"
Or
<FilesMatch"\.php$">
SetHandler application/x-httpd-php-cgi
</FilesMatch>
Action application/x-httpd-php-cgi "/php-cgi/php-cgi.exe"
Scenario 2: Exposing the PHP binary (also the default XAMPP configuration)
Even if PHP is not configured under the CGI mode, merely exposing the PHP executable binary in the CGI directory is affected by this vulnerability, too. Common scenarios include, but are not limited to:
- Copying
php.exe
orphp-cgi.exe
to the/cgi-bin/
directory. - Exposing the PHP directory via
ScriptAlias
directive, such as:ScriptAlias /php-cgi/ "C:/xampp/php/"
Mitigation Measure
It is strongly recommended that all users upgrade to the latest PHP versions of 8.3.8, 8.2.20, and 8.1.29. For systems that cannot be upgraded, the following instructions can be used to temporarily mitigate the vulnerability.
However, since PHP CGI is an outdated and problematic architecture, it’s still recommended to evaluate the possibility of migrating to a more secure architecture such as Mod-PHP, FastCGI, or PHP-FPM.
1. For users who cannot upgrade PHP:
The following Rewrite Rules can be used to block attacks. Please note that these rules are only a temporary mitigation for Traditional Chinese, Simplified Chinese, and Japanese locales. It is still recommended to update to a patched version or migrate the architecture in practice.
RewriteEngineOnRewriteCond %{QUERY_STRING} ^%ad [NC]
RewriteRule .? - [F,L]
2. For users who use XAMPP for Windows:
XAMPP has not yet released corresponding update files for this vulnerability at the time of writing this article. If you confirm that you do not need the PHP CGI feature, you can avoid exposure to the vulnerability by modifying the following Apache HTTP Server configuration:
C:/xampp/apache/conf/extra/httpd-xampp.conf
Locating the corresponding lines:
ScriptAlias /php-cgi/ "C:/xampp/php/"
And comment it out:
# ScriptAlias /php-cgi/ "C:/xampp/php/"
Timeline
- 2024/05/07 - DEVCORE reported this issue through the official PHP vulnerability disclosure page.
- 2024/05/07 - PHP developers confirmed the vulnerability and emphasized the need for a prompt fix.
- 2024/05/16 - PHP developers released the first version of the fix and asked for feedback.
- 2024/05/18 - PHP developers released the second version of the fix and asked for feedback.
- 2024/05/20 - PHP entered the preparation phase for the new version release.
- 2024/06/06 - PHP released new versions 8.3.8, 8.2.20, and 8.1.29.