A single Unicode character — a soft hyphen buried in an HTTP request — gave unauthenticated attackers the ability to run arbitrary code on Windows servers. CVE-2024-4577 was weaponized within 48 hours of disclosure, added to the CISA Known Exploited Vulnerabilities catalog six days later, and is still being actively exploited in mass campaigns across at least nine countries as of early 2025.
Key Takeaways
- CVE-2024-4577 is a critical (CVSS 3.1: 9.8) argument injection flaw in PHP-CGI on Windows, allowing unauthenticated remote code execution.
- The vulnerability was discovered by Orange Tsai of Devcore and patched by the PHP Group on June 6, 2024; WatchTowr published a PoC the next day.
- CISA added CVE-2024-4577 to its Known Exploited Vulnerabilities catalog on June 12, 2024, with a federal remediation deadline of July 3, 2024.
- The TellYouThePass ransomware group began exploiting the flaw within days of disclosure; subsequent campaigns delivered Gh0st RAT, RedTail cryptominers, XMRig, and a novel backdoor called Msupedge.
- Mass exploitation escalated through late 2024 and into 2025, with GreyNoise detecting over 1,000 unique attacker IPs in January 2025 alone.
- Fix: update PHP on Windows to 8.1.29, 8.2.20, or 8.3.8. If immediate patching is impossible, disable PHP-CGI or switch to PHP-FPM.
What exactly is CVE-2024-4577?
CVE-2024-4577 is an OS command injection vulnerability (CWE-78) affecting PHP when it runs in CGI mode on Windows. The CVSS 3.1 base score is 9.8 Critical, with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Translated: network-reachable, low complexity, no privileges required, no user interaction, full impact on confidentiality, integrity, and availability. [1]
The scoring reflects the reality: if a web server running Apache with PHP-CGI on Windows is exposed to the internet and hasn't been patched, an attacker can reach it, send a crafted HTTP request, and execute code — without logging in, without any special account, without any interaction from a victim clicking a link. That combination of conditions is exactly what makes this class of vulnerability so dangerous.
PHP-CGI refers to the Common Gateway Interface mode in which a web server doesn't handle PHP natively but instead spawns a PHP process for each request. Windows machines running XAMPP and certain shared hosting configurations use this mode by default, which means the attack surface was unusually broad when the flaw was disclosed.
How does the vulnerability actually work?
The mechanism is a descendant of a very old bug. CVE-2012-1823, patched twelve years earlier, also involved argument injection in PHP-CGI. The old fix told Apache to escape real hyphens (0x2D) so they couldn't be smuggled in as PHP command-line flags. CVE-2024-4577 found a way around that patch entirely. [2]
Here's the key detail. Windows has a feature called Best-Fit character mapping, which converts Unicode characters to their closest ASCII equivalent. A soft hyphen — Unicode code point 0xAD, a typographical character that indicates where a word can be broken across a line — gets mapped to a standard hyphen, 0x2D, by Windows during character encoding conversion. Apache never escapes the soft hyphen because, to Apache, it isn't a hyphen. PHP, running on Windows, then applies Best-Fit mapping and converts the soft hyphen to a real hyphen, treating what arrives as a command-line argument delimiter. [3]
An attacker sends an HTTP GET request with a URL-encoded soft hyphen (%AD) in the query string, followed by PHP flags such as -d allow_url_include=1 -d auto_prepend_file=php://input. Those flags tell the PHP binary to accept remote files and prepend them to execution. The HTTP request body then contains arbitrary PHP code. The result is unauthenticated remote code execution on the server.
The flaw only applies when PHP runs in CGI mode on Windows. Importantly, if php.exe or php-cgi.exe are in a directory accessible to the web server, the server can be vulnerable even without CGI mode being explicitly configured. XAMPP installations, which set up this layout by default, were among the most exposed systems.
Who discovered it, and when was it patched?
The vulnerability was discovered by Orange Tsai, principal security researcher at Devcore, who reported it to the PHP Group on May 7, 2024. The PHP Group released fixes on June 6, 2024: PHP 8.1.29, 8.2.20, and 8.3.8 all address the issue. [4]
WatchTowr published a detailed technical analysis along with proof-of-concept exploit code on June 7 — one day after the patch dropped. That same day, the Shadowserver Foundation reported observing exploitation attempts against internet-facing systems. A Metasploit module was added in mid-2024, and at least 79 public exploit variants were eventually catalogued. [3]
The PHP Group's advisory confirmed that all versions of PHP 8.1.x before 8.1.29, 8.2.x before 8.2.20, and 8.3.x before 8.3.8 on Windows are affected. End-of-life PHP versions — including PHP 5.x and PHP 7.x — also contain the vulnerability but received no official patches.
Which systems are affected?
| PHP Version | Affected Range | Fixed Version | Platform |
|---|---|---|---|
| PHP 8.3.x | Before 8.3.8 | 8.3.8 | Windows (CGI mode) |
| PHP 8.2.x | Before 8.2.20 | 8.2.20 | Windows (CGI mode) |
| PHP 8.1.x | Before 8.1.29 | 8.1.29 | Windows (CGI mode) |
| PHP 7.x | All versions | No patch (EOL) | Windows (CGI mode) |
| PHP 5.x | All versions | No patch (EOL) | Windows (CGI mode) |
Linux systems are not affected by CVE-2024-4577 because the Best-Fit character encoding behavior is specific to Windows. PHP running on Windows in non-CGI modes (mod_php, PHP-FPM) is also not directly exploitable through this flaw, though security researchers noted that exposure can extend to cases where php.exe or php-cgi.exe sit in directories accessible to the web server, even without explicit CGI mode configuration. [1]
Censys counted approximately 458,800 potentially vulnerable PHP server instances as of June 9, 2024 — two days after the patch was available. The exposure was concentrated primarily in the United States and Germany. The figures reflect how common Windows-based PHP deployments remain, particularly in shared hosting environments and legacy XAMPP setups.
For organizations running a structured vulnerability management program, identifying PHP-CGI installations on Windows should have been a straightforward scan. The challenge in practice was that many of those installations were unmanaged, belonged to third-party software bundles, or predated any modern asset inventory.
Was CVE-2024-4577 actually exploited in the wild?
Yes — confirmed by multiple independent sources and by CISA's direct KEV listing. This isn't a case of a theoretical flaw or a PoC that never made it to real attacks. [5]
The sequence is documented. The Shadowserver Foundation observed exploitation attempts within 24 hours of the patch release. On June 8, 2024 — two days after patching and one day after the PoC dropped — the TellYouThePass ransomware group began hitting servers, using mshta.exe (a legitimate Windows binary) to download and execute their payload in a living-off-the-land style. Imperva tracked victims; Censys published a dashboard showing infected hosts. [6]
The campaign didn't stop at ransomware. By July 2024, Akamai's Security Intelligence Response Team reported multiple threat actors delivering Gh0st RAT (a remote access trojan), RedTail cryptocurrency miners, and XMRig. In August 2024, Symantec disclosed that attackers had deployed a new backdoor — Msupedge — against a university in Taiwan by exploiting this same CVE. Each of those represents a separate threat actor making a separate decision to use CVE-2024-4577 as an entry point.
The exploitation continued to escalate rather than taper off. Cisco Talos reported in early 2025 that a campaign targeting Japanese education, e-commerce, and telecommunications organizations had been running since at least January 2025. GreyNoise's global honeypot network recorded 1,089 unique IP addresses attempting exploitation in that one month alone. [9] More than 43% of those IPs were tracked to Germany and China.
Why did this particular flaw spread so quickly?
Speed of weaponization is one factor, but it's not the only thing that made this flaw so widely exploited. A handful of structural conditions combined to make it persistent.
First, the PoC appeared before most administrators had time to patch. A 24-hour gap between a patch and a public working exploit is operationally brutal for teams that don't have automated patching pipelines. If PHP runs on a server managed by a third-party software bundle, the server owner may not even know the language is installed. XAMPP is a classic example — a developer tool that ships with Apache and PHP, often installed and forgotten, often exposed with default settings.
Second, affected end-of-life PHP versions received no patch. Organizations running PHP 5.x or 7.x — both long past support — have no official fix available. They must either upgrade to a supported version or implement mitigations, neither of which is quick in production environments.
Third, automated scanning drove volume. GreyNoise's data showed the surge was not just a handful of sophisticated actors — it was automated tooling probing for the vulnerable endpoint at scale, which is why 1,089 unique attacker IPs could generate meaningful activity within a single calendar month.
For teams that rely on CVSS scores to prioritize patching, a 9.8 Critical with no prerequisites should have cleared any triage queue immediately. The problem isn't score interpretation — it's patch lag on systems that weren't tracked in asset inventories.
What should organizations do now?
If PHP is running on Windows in any capacity — including as part of a software stack, WAMP/XAMPP installation, or web application framework — the first question is whether it has been updated. The fix is straightforward for supported versions.
- Primary remediation: Update PHP to 8.1.29, 8.2.20, or 8.3.8 on all Windows servers. If the installed version is PHP 7.x or PHP 5.x, upgrade to a supported branch — no patch exists for those releases.
- If patching is delayed: Disable PHP-CGI entirely if it's not required, or switch to PHP-FPM (FastCGI Process Manager), which is not affected by this vulnerability.
- WAF/IDS rules: Block HTTP requests containing
%AD(URL-encoded soft hyphen) in query strings targeting PHP scripts. Multiple vendors have published specific signatures. - Inventory check: Identify every Windows server where php.exe or php-cgi.exe is present in a directory reachable by the web server, not just those explicitly configured for CGI mode.
- XAMPP specifically: Default XAMPP configurations place the PHP binary in a CGI-accessible location. These deployments are vulnerable even if not intentionally running a PHP web application.
- Review logs: Look for GET requests to PHP endpoints with unusual query strings, particularly those containing
%AD,allow_url_include, orauto_prepend_file.
For organizations that want to detect whether systems were already compromised before patching, the payloads observed include web shells, Msupedge, and TellYouThePass ransomware artifacts. A review of incident response procedures and web shell indicators on affected servers is warranted for any unpatched system that was internet-exposed during the window between June 6 and the date of patching.
What remains uncertain?
Total victim count is unknown. Ransomware groups don't publish victim lists by CVE, and many compromises go unreported or undetected. The exploitation data from GreyNoise reflects scanning and attack attempts — what percentage of those resulted in successful compromise is not publicly documented.
Attribution for several of the 2024–2025 campaigns has not been established. Cisco Talos identified Japan-targeting activity but did not name a specific threat actor in its initial reporting. The Msupedge backdoor used in the Taiwan university breach was described as novel by Symantec, but its operator has not been publicly attributed to a named group or state-sponsored actor.
It also isn't clear how many of the thousands of potentially vulnerable servers identified by Censys in mid-2024 have since been patched, migrated, or taken offline. GreyNoise's continued detection of active scanning in early 2025 suggests meaningful unpatched exposure persists.
Organizations that have response plans for ransomware and monitor for web shell indicators should continue to treat this CVE as an active threat rather than a resolved historical event.
Strategic Implications
CVE-2024-4577 illustrates something that gets understated in post-mortems: patch windows are not symmetric. A vendor has months or years to fix a vulnerability before it's discovered. Once it's public, defenders have hours. WatchTowr published exploit code the day after patching; TellYouThePass hit servers two days later. The CISA KEV listing came six days in. By that point, unpatched internet-facing servers in any organization that runs quarterly patch cycles had already been exposed to a weaponized exploit for most of that window.
The flaw's lineage is also worth noting. This was a bypass of a bug patched in 2012. Character encoding edge cases — particularly those involving Windows's Best-Fit Unicode mapping — are genuinely difficult to fully audit, and the original fix for CVE-2012-1823 left a gap that went unnoticed for twelve years. That's not negligence; it's the nature of handling encoding complexity at the intersection of two independently developed systems.
The range of payloads observed — ransomware, RATs, cryptominers, novel backdoors, Cobalt Strike beacons — confirms what defenders should already assume: a well-known critical RCE vulnerability will be picked up by actors across the entire threat spectrum, not just the most sophisticated ones. Automated scanning commoditizes access to the exploit. The actors deploying Cobalt Strike are different from the ones running cryptominers, but they're all walking through the same door.
For defenders, the practical lesson is less about this CVE specifically and more about where the process failed. A vulnerability management program that lacks asset visibility into Windows PHP installations, or that relies on manual patching cycles measured in weeks, will consistently lose the race. The CISA KEV catalog exists precisely to provide a bounded, high-confidence list of vulnerabilities that require priority attention — CVE-2024-4577 should have been tracked against that list the same day it appeared on it.
Sources & References
- NIST NVD — CVE-2024-4577 Detail
- Devcore (Orange Tsai) — Security Alert: CVE-2024-4577 PHP-CGI Argument Injection Vulnerability
- WatchTowr Labs — No Way, PHP Strikes Again! (CVE-2024-4577)
- PHP Group — PHP 8.1.29 Changelog
- CISA Known Exploited Vulnerabilities Catalog
- Help Net Security — PHP command injection flaw exploited to deliver ransomware (CVE-2024-4577)
- Security Affairs — Experts warn of mass exploitation of critical PHP flaw CVE-2024-4577

Leave a Comment (Authenticated Users)