CVE-2024-8926 - New Command Injection Risk in PHP on Windows Even After CVE-2024-4577 Patch
In June 2024, a new vulnerability, CVE-2024-8926, was found in PHP versions 8.1, 8.2, and 8.3 running on Windows. Even after patching an earlier bug, CVE-2024-4577, PHP users with certain non-default codepage setups remain at risk of command injection. This flaw could let hackers run any code they want or leak your PHP source code.
In this post, we’ll explain what’s going on in simple terms, look at sample exploits, and discuss how to protect your PHP server on Windows.
What is CVE-2024-8926?
After the big “Best Fit” codepage bug (CVE-2024-4577) in PHP was fixed, researchers found another path: with some rare Windows codepage configurations, the patch can be bypassed. If an attacker can control input that’s passed to PHP’s command-line interface (CLI) on the server (such as from user requests), they might inject special characters that “trick” Windows into misreading the command, letting them inject options into the PHP binary.
Compromise the entire server
*Note*: This only affects servers running PHP on Windows with these specific, non-standard codepage settings.
PHP 8.3: Below 8.3.12
- Only on Windows with unusual codepage config (NOT default codepage 65001/UTF-8 or 1252 for English Windows).
Is your server at risk? You may not know unless you deliberately changed Windows’ “system locale” or codepage settings for legacy software. But many shared hosts and older setups *do* use "Best Fit" codepages to support various languages.
Digging Deeper: How Does the Exploit Work?
The original CVE-2024-4577 issue involved Windows' "Best Fit" feature, which tries to convert Unicode characters into a similar looking character in a different codepage. PHP did not sanitize these inputs well, and hackers could insert bytes that were misread as valid arguments.
The fix for CVE-2024-4577 blocked this—*except*:
If you use a rare codepage, some sneaky bytes still slip through.
Suppose PHP is invoked like this by an HTTP server (this is common in CGI/FastCGI setups)
php-cgi.exe myscript.php
If the attacker knows the system codepage (say, SHIFT-JIS for Japanese Windows), they can submit the filename as parameters that, *after character conversion*, are translated by Windows into something like:
php-cgi.exe -d allow_url_include=on -r "system('whoami');" myscript.php
PHP then executes the attacker’s code (system('whoami');).
They might request
GET /cgi-bin/php-cgi.exe/%FA%80%80%80 HTTP/1.1
Where the %FA%80%80%80 bytes, in this codepage, decode to -d allow_url_include=on ... instead of a simple file path.
> Why does this bypass the patch?
> Because the original patch didn’t see this weird “alternate” byte sequence as dangerous in non-standard codepages.
An attacker requests
http://yoursite.com/cgi-bin/php-cgi.exe/%5C%81%40%22%2D%72%22cat%20C%3A%5Cinetpub%5Cwwwroot%5Csecret.php
In this specific codepage, the URL decodes as
php-cgi.exe "-r" "cat C:\inetpub\wwwroot\secret.php"
Running under codepages with “Best Fit” mappings (SHIFT-JIS, GBK, Big5, etc.)
- User input is passed unchecked to PHP (very common in CGI/FastCGI)
If you use the default English codepage 1252 or Unicode 65001, you're safe. But any codepage change for Asian/legacy compatibility—you're at risk!
You can view your system’s codepage using Command Prompt
chcp
If this returns 932 (SHIFT-JIS), 936 (GBK), 950 (Big5), etc., you’re exposed!
Or, as PHP
<?php
echo 'Current codepage: '.exec('chcp');
?>
8.3.12 or newer
2. Switch to Safer Codepage
If possible, change your system locale to English/US (codepage 1252) or UTF-8 (65001). This prevents “Best Fit” tricks.
### 3. Disable CGI / FastCGI if Unneeded
If possible, don’t invoke php-cgi.exe directly via user-controlled input.
4. Deploy Web Application Firewall
WAFs may block weird encodings, but don’t rely on them alone.
References
- Official PHP Advisory for CVE-2024-4577 (GHSA-vxpp-6299-mxw3)
- PHP’s own security page
- Original Patch Commit (github.com/php/php-src)
- Security researcher blog on codepage attacks (external)
Monitor your server logs for unusual requests.
Remember: These bugs are tricky because they rely on deep OS features, not just PHP code. Stay safe by staying up to date, and keep an eye on your system configuration.
If you found this post useful, share it with your team! If you have more questions about server security, reach out!
Timeline
Published on: 10/08/2024 04:15:10 UTC
Last modified on: 10/16/2024 18:35:59 UTC