php2shell isnow in use.
Last week we explained php2shell, two serious flaws in PHP. This week it moved from a warning to real break-ins, and the US cyber security agency told its own departments to fix it by Thursday. Here is how the attack works, what we found when we checked 481 small business websites, and the two questions to ask your host.
What changed
On 26 October, the US cyber security agency, CISA, added both php2shell flaws (CVE-2026-109618 and CVE-2026-109619) to its list of known exploited vulnerabilities. That list only holds flaws it has evidence attackers are using, not flaws they might use one day. US government departments have until 29 October to fix them.
The same day, the security firm Trail of Bits said working attacks exist for every supported version of PHP before the fix, from 8.2 to 8.5. If you want to know how the flaws work underneath, our plain English explainer covers it. This piece is about what has happened since.
The week in dates
- 17 October. Amazon's security team sees someone try the flaws on its decoy servers, four days before anyone else knew they existed.
- 20 October. Details leak online a day early.
- 21 October. PHP releases the fix. Cloudflare says it is already seeing early attacks.
- 21 and 22 October. CloudLinux, the system under a lot of shared hosting, ships fixed PHP for its customers, all the way back to PHP 5.2.
- 24 October. The first confirmed break-ins.
- 26 October. CISA adds both flaws to its list of flaws in use.
How the attack works
Security companies recorded millions of attempts in the first few days, but none were confirmed to have worked. That changed on 24 October, when a researcher at Perplexity, Adel Karimi, caught 35 successful break-ins on decoy servers set up to look like ordinary PHP websites. They came from two internet addresses.
Each attack was a short run of ordinary looking web requests, in three kinds:
- Fill the memory. Requests built to make PHP run out of memory part way through a visit, which is the first flaw.
- Read the leftovers. Requests that read what earlier visits left behind in memory, which is the second flaw. That tells the attacker where things are, so the last step lands.
- Run a command. The last request makes the server run a command of the attacker's choosing. From there they can do anything the website itself can do: read the database, change pages or leave a program behind to come back through later.
No login, form or plugin is involved. The traffic matched attack code that has been shared online, so anyone can copy it.
What we found on local websites
On 25 and 26 October, we ran the free Mendbird check on 481 small business websites in Somerset, Dorset, Devon and Wiltshire: shops, trades, garages, B&Bs and the like. 196 run on PHP in a way we could see, mostly through WordPress, and 92 of those tell every visitor exactly which PHP version they use.
- 55 showed a fixed version. Their hosts had already updated within five days of the fix.
- 4 showed a version from before the fix, on a line that has one.
- 33 run PHP 8.1 or older, including 15 on PHP 7.4 and 2 on PHP 5.6, which came out in 2014. PHP itself has no fix for any of these.
That last group is not as bad as it sounds, and the reason is worth knowing. Hosts that use cPanel and CloudLinux got fixed copies of old PHP versions within a day of the fix, but those copies kept their old version number. So a site can say 7.4.33 and be safe, or say 7.4.33 and be wide open. From the outside, nobody can tell. Only your host can.
Who is most at risk
PHP says every setup is affected, but some are easier to attack than others. The decoys that were broken into ran PHP inside the Apache web server (often called mod_php), handling one visit at a time. That is the setup PHP itself rates as most at risk, because the attack can work before any of the website's own code runs. It is also common on older and cheaper shared hosting, where a lot of small business sites live.
The researcher was clear that his decoys were the easy case, and do not show how often the attack works elsewhere. But attack code only improves, and one security researcher roughly estimates over 1.3 million servers on the internet could be open to it. A PHP site that has not been updated is at risk now, not one day.
What to do now
There are two questions, and the second one is the one most people skip.
Is it fixed? If your host or developer confirmed the update last week, there is nothing new to install. If the answer is PHP 8.1 or older, ask whether they have their own fix, because PHP does not.
Did anyone get in first? Attacks started before the fix existed, so a site that was updated on 22 October could still have been broken into on 18 October. CISA asks organisations to check, and Amazon advises looking back to 17 October. The signs a host or developer can look for:
- new PHP files in places that should only hold pictures and uploads
- website admin accounts nobody remembers making
- files changed since 17 October that nobody changed
- scheduled tasks on the server that nobody set up
Ask your developer“Is our website’s PHP fixed for php2shell (CVE-2026-109618 and CVE-2026-109619), and on what date? And have you checked the server for signs that anyone got in from 17 October onwards?”
If your host is slow to answer either question, that tells you something about how they would handle the next one.
How Mendbird helps
The free Mendbird check reads the PHP version your site shows to every visitor, and marks an affected version Dangerous, with the version that fixes it. When a site hides its version, which is good practice, the report says so rather than guess.
The optional Mendbird helper reads the real version from inside your site, along with every plugin, so the answer does not depend on what the site chooses to show. And on a Watch plan, the Mendbird checks every morning and emails you the day something serious is new.