A PHP flaw first fixed in 2012 found its way back on Windows servers in 2024 as CVE-2024-4577. Ransomware attacks followed within days. Here's what happened, who was exposed, and why ageing PHP setups deserve a closer look.
Some security flaws don't stay fixed. In 2012, the PHP project patched a flaw that let anyone on the internet send instructions directly to PHP and run their own code on the server. Twelve years later, a researcher found a way to slip the same attack past that fix on Windows.
The new flaw, CVE-2024-4577, was rated 9.8 out of 10 for severity. Ransomware attacks using it were reported within two days of the fix. The US Cybersecurity and Infrastructure Security Agency (CISA) lists it as known to be used in ransomware campaigns, and attacks using it were still being reported in 2025.
Most PHP websites were never exposed, and it is worth being precise about who was. But the systems that were exposed fit a familiar pattern: an old way of running PHP, a development tool used as a live server, and PHP versions past their end-of-life. For any business with older Windows servers running PHP, that pattern is worth understanding.
What the PHP-CGI flaw is, in plain terms
CGI is one of the oldest ways of connecting a web server to a program such as PHP. In some setups, part of the web address a visitor requests is handed to PHP as a set of instructions, a bit like typing commands into it directly. Some of those instructions are powerful enough to make PHP run code supplied by whoever sent the request.
The original flaw, 2012. CVE-2012-1823 let attackers do exactly that on servers running PHP through CGI. PHP fixed it on 3 May 2012 by adding a check that blocked requests trying to pass instructions in this way. Ten years later, in March 2022, CISA added it to its Known Exploited Vulnerabilities catalogue, its list of flaws with evidence of real-world attacks.
The bypass, 2024. In May 2024, Orange Tsai of the Taiwanese security firm DEVCORE reported a way around the 2012 check. On Windows, text can be automatically converted between character sets, and in doing so Windows sometimes swaps one character for a similar-looking one. Under Japanese, Simplified Chinese and Traditional Chinese language settings, a character that PHP's check let through was quietly converted into exactly the character the check was meant to stop. By the time PHP read the request, the protection had been sidestepped.
According to DEVCORE, an attacker didn't need to log in. The affected setups were Windows servers using those language settings, either running PHP through CGI or exposing the PHP program directly, which was the default in XAMPP, a popular bundle for running PHP on a Windows computer. DEVCORE said all XAMPP installations on Windows were vulnerable by default in those locales. For other language settings, including English, it said it could not rule out every way the flaw might be exploited. PHP on Linux was not affected.
What could go wrong for your business
In this case, the worst outcomes were not hypothetical. Imperva reported that "from as early as June 8th", two days after PHP released its fix, attackers were using the flaw to deliver TellYouThePass ransomware, which encrypts files and leaves a ransom note on the website. CISA added the flaw to its catalogue on 12 June 2024 and marks its use in ransomware as "Known".
The attacks continued. In March 2025, Cisco Talos reported that an unknown attacker had been using the flaw since at least January 2025 to break into organisations "predominantly" in Japan, across technology, telecoms, entertainment, education and e-commerce. Once inside, the attacker installed remote-control tools, gained full control of the machine, stole stored passwords, erased activity logs and tried to move on to other computers on the network.
For a business, that kind of intrusion can mean:
- Encrypted files and lost access to the website or systems until they are restored or rebuilt.
- Exposure of customer and business data, including passwords that may open other systems.
- A wider breach, since a single compromised server can become a way into the rest of the network.
- Significant recovery costs and disruption to normal operations.
- Damage to trust with customers and partners, and possible reporting obligations depending on the data involved.
Not every exposed server suffered these outcomes, but they were reported for real organisations.
Could your website be next?
Attackers often use automated tools to scan large numbers of servers for known weaknesses. They don't need to know who owns a server or what it is for. A test machine, an internal tool or a server set up "temporarily" years ago can be found as easily as a company's main website, simply because it is reachable from the internet.
That matters here because the servers most likely to be exposed were exactly the ones that tend to be forgotten: older Windows machines, development bundles that became live servers, and setups nobody has revisited since they were built. Ransomware attacks were reported within two days of the fix, so there was very little time to act for anyone who didn't know these servers existed.
This doesn't mean every PHP server is at risk. Current PHP on Linux was never exposed, and many Windows setups weren't either. But never having had an incident is not proof of safety, particularly for systems nobody is watching.
Why legacy PHP applications deserve attention
Every condition behind CVE-2024-4577 is a legacy one.
An old way of running PHP. CGI predates the setups most PHP sites use today. DEVCORE's own advice was to consider moving to a more modern arrangement. Systems still on CGI are usually there because nobody has revisited them.
A development tool in production. XAMPP is designed to make it easy to run PHP on a developer's own computer. It is not designed to be a live server facing the internet, but it sometimes becomes one. A default that is harmless on a laptop becomes dangerous on a public server.
An end-of-life PHP version. The fix only shipped for PHP 8.1, 8.2 and 8.3. DEVCORE noted that PHP 8.0, 7 and 5 are no longer maintained and would not get a fix. A Windows server left on PHP 7.4 had no official fix at all.
A fix that only holds if nothing changes. The 2012 fix made an assumption about how text would arrive. That held on Linux, but Windows broke it. Old code running in environments its authors never considered is where such assumptions fail.
This pattern isn't new. CISA's catalogue also lists a separate flaw in PHP-FPM, another common way of running PHP, as used in ransomware.
To be fair, the PHP project fixed CVE-2024-4577 within a month of it being reported. Any platform can have a critical flaw, Node.js included. The lesson is that old deployment choices and unsupported versions can turn a narrow flaw into a ransomware incident.
What this means for your organisation
The first question is visibility. Do you know every Windows server in your organisation that runs PHP, including internal tools, test machines and anything installed with a bundle like XAMPP? Do you know which PHP version each one runs, and how it is set up?
If any of those servers were exposed while vulnerable, the question is also whether anyone has checked them for signs of compromise.
A server like this is often a sign of something larger: an application that has run untouched for years because nobody was sure how to change it safely. Understanding its real condition is the first step towards deciding whether to bring it up to date, replace it or retire it.
Recommended next step
If you have older PHP systems, especially on Windows, take our free Legacy PHP Risk Assessment. It can help you understand how your PHP applications are deployed, which versions they run, and where old setups like CGI or development bundles may be leaving you exposed.
Then talk to our team about the right way forward. Depending on the application, that might be an upgrade to a supported setup, or a planned rebuild on a modern stack such as Node.js, deployed in a repeatable way onto supported versions. No platform is free of flaws, and every stack needs maintaining. The goal is a system your team can see, update and trust.
Free Legacy PHP Risk Assessment
Not sure how your PHP applications are deployed, or which servers might be running old setups? We'll review your PHP versions, server configuration, hosting and dependencies, and explain plainly where you're exposed and what your options are.
