PHP-CGI Argument Injection RCE on Windows (CVE-2024-4577) Explained

Some of the most dangerous vulnerabilities are not new bugs but old ones that a small environmental detail brings back to life. CVE-2024-4577 is a perfect example. Discovered by Orange Tsai of DEVCORE and disclosed on June 6, 2024, it is an argument-injection flaw in PHP running in CGI mode on Windows — and it is a direct bypass of the fix for a 2012 vulnerability, CVE-2012-1823, that everyone assumed had been settled for over a decade. The mechanism hinges on a quirk of how Windows converts characters, and it yields unauthenticated remote code execution. It was rated critical, added to CISA's KEV catalog, and exploited within days by the TellYouThePass ransomware crew.

Vulnerability identity and severity

CVE-2024-4577 is an argument-injection vulnerability in the PHP-CGI executable on Windows. It carries a CVSS 3.x base score of 9.8 (Critical). When PHP runs in CGI mode (or where php-cgi.exe is otherwise exposed, as in some default XAMPP configurations), an attacker can inject command-line arguments into the PHP interpreter, override configuration directives, and force execution of attacker-supplied PHP code — all without authentication.

Timeline and impact

• June 6, 2024 — DEVCORE discloses the flaw and the PHP project simultaneously releases patched versions.
• Within days — public proof-of-concept exploits circulate and mass scanning begins; the TellYouThePass ransomware operation is observed exploiting it.
• Shortly after — CISA adds CVE-2024-4577 to the Known Exploited Vulnerabilities catalog.

The impact is unauthenticated RCE on affected Windows PHP deployments. The advisory highlighted that servers configured with certain locales — Traditional Chinese, Simplified Chinese, and Japanese code pages — were exploitable in default configurations, but the PHP team urged all Windows PHP-CGI users to patch, since the safest assumption is broad exposure rather than a narrow locale carve-out.

Root cause: the Windows "best-fit" mapping

CVE-2012-1823 was the original PHP-CGI argument-injection bug: PHP-CGI would interpret query-string content as command-line arguments when no = sign was present, letting an attacker pass switches like -d to the interpreter. PHP fixed that by filtering the dangerous characters — including the hyphen (-, 0x2D) that begins a command-line switch.

The bypass exploits Windows "best-fit" character mapping. When Windows converts certain Unicode characters into the active code page, it substitutes a visually or semantically similar character for one that has no direct representation. In particular, a soft hyphen (0xAD) can be best-fit-mapped to a real hyphen (0x2D) after PHP's input filtering has already run. So an attacker sends a soft hyphen, PHP's sanitizer sees a harmless character and passes it through, and then the Windows layer helpfully "corrects" it into the very hyphen the sanitizer was trying to block. The filtered switch is reconstituted downstream.

Once an attacker can inject a hyphen, they can inject arguments. The classic escalation supplies configuration overrides that turn the request body into executable code (safe, conceptual illustration — not a working exploit):

-d allow_url_include=1 -d auto_prepend_file=php://input

auto_prepend_file=php://input tells PHP to execute the raw request body as PHP before running the requested script, and allow_url_include=1 enables the wrapper. The result is straightforward remote code execution. The entire chain rides on a character-encoding detail that has nothing to do with PHP's own logic — which is exactly why it slipped past a fix that had held for twelve years.

Detection

• Determine whether you run PHP-CGI on Windows. This vulnerability is Windows-specific and tied to CGI mode; Linux deployments and PHP-FPM/mod_php setups are not affected by this particular flaw.
• Check for exposed php-cgi.exe, including bundled stacks like XAMPP where CGI may be enabled by default.
• Review web server logs for requests containing soft hyphens (encoded such as %ad) followed by d and configuration directive names like allow_url_include or auto_prepend_file.
• Confirm your PHP version; anything below the patched releases below, on Windows CGI, is at risk.

Remediation and patched versions

1. Upgrade PHP to a fixed release — 8.3.8, 8.2.20, or 8.1.29 or later. Note that PHP 8.0 and earlier are end-of-life; if you are on an unsupported branch, upgrade to a supported one.
2. Move off CGI mode. The most robust structural fix is to stop using PHP-CGI entirely, migrating to PHP-FPM or mod_php, which are not affected by this argument-injection path.
3. If you cannot patch immediately, apply web-server rewrite rules that block requests carrying the dangerous character sequences from reaching php-cgi.exe, and disable the cgi.force_redirect-adjacent exposures per PHP's guidance.
4. For XAMPP and similar bundles, disable the PHP-CGI handler if you are not deliberately using it.
5. Re-verify after patching that crafted soft-hyphen arguments no longer reach the interpreter, and treat any exposed-and-unpatched server as potentially compromised — hunt for webshells and unexpected scheduled tasks.

How Safeguard helps

CVE-2024-4577 is a reminder that a runtime's exact version and its deployment mode together decide your risk. Safeguard's software composition analysis fingerprints the PHP version embedded in your services and container images and flags any build below 8.1.29 / 8.2.20 / 8.3.8, so a stale interpreter in a Windows image does not slip through unnoticed. Because this flaw is only exploitable on a reachable CGI endpoint, Safeguard's DAST engine probes your deployed surface to confirm which servers actually expose the vulnerable path, turning a version list into a prioritized, live finding. The Safeguard CLI runs the same detection inside CI and container builds, so a vulnerable PHP layer fails the pipeline before it ships. If you are comparing this combined component-and-exposure model against a single-vendor scanner, read Safeguard versus Snyk, and see transparent pricing.

The best-fit bypass shows how a patched, understood vulnerability can return through a detail no one was watching. Version-accurate inventory plus runtime confirmation is what keeps a twelve-year-old bug from becoming today's incident. Create a free Safeguard account or read the documentation to get started.