On October 21, PHP shipped emergency patches for two critical flaws that let anyone run their own code on your server. PHP powers seven in ten websites. That same day, Finland took government websites offline.
If your site runs on WordPress, on shared hosting, or on anything someone built "in PHP", this is about you. And odds are nobody told you.
What happened
The flaws were filed as CVE-2026-109618 and CVE-2026-109619, scored 9.2 out of 10. Both are *remote code execution*: whoever exploits them does not steal a stray record, they take over the server. The security press named them PHP2Shell.
According to researchers at Wiz, who took part in the discovery, every PHP version released in the last decade carries at least one of the two: PHP 5.4 onward. Wiz coordinated disclosure with the PHP team before it went public.
Why the blast radius is so large
PHP runs on about 70% of websites whose language can be identified, according to W3Techs. Estimates built on Netcraft’s surveys put active sites on the internet at around 200 million. Do the math: we are talking about more than a hundred million sites.
And these are not just old blogs. PHP runs WordPress, which runs a large share of the shops, portfolios and business pages out there. As Wiz put it: PHP lives across clouds, hosting providers, CDNs and millions of independently managed servers.
Half of them will never get the fix
This is the part that turns a bad week into a problem measured in years. Only PHP 8.2 or newer gets the patch. Everything older is out of support, so nobody is going to publish a fix for those versions.
According to Cisco, roughly half of internet-facing PHP installs run one of those versions. For them there is no "update and done": the only way out is a version upgrade, with everything that breaks on a site nobody has touched in years.
Governments, companies, and an exploit built in under an hour
The reaction was immediate. Finland took government sites offline, the Dutch parliament took its own down, and Nintendo switched off services while it patched. That was not panic: it was the responsible call, because the window to do this calmly no longer exists.
According to The Record, building a working exploit with the help of AI took under an hour. There used to be days between a flaw going public and mass exploitation. Now, anyone running a site who does not catch the news that same morning is already late.
How to tell whether your site runs PHP, and which version
You do not need to be a developer. Try these in order:
- If it is WordPress, it runs PHP. In the dashboard go to Tools → Site Health → Info → Server: the exact version is listed there.
- If you are on shared hosting (cPanel, Plesk or similar), look for something like "Select PHP Version" or "PHP Manager". The active version is shown right there.
- If you do not know how it was built, open a terminal and run
curl -I https://yoursite.com. If the response showsX-Powered-By: PHP/7.4, that is your number. (If it does not show up, that rules nothing out: many servers hide it.) - If someone else built it, ask them one thing: "which PHP version does my site run?". If they do not know, that is an answer too.
One warning: if someone uploads a phpinfo.php file to find out, have them delete it afterwards. That file tells anyone exactly what you have installed, and it is one of the first things automated scanners look for.
What to do today, depending on what you found
- 8.2 or newer: update to the patched release of your branch today. On managed hosting it is usually a button; if you cannot find it, ask support whether they have applied it.
- Older than 8.2: there is no patch for you. Upgrade — on a copy of the site first, because old plugins and themes break — and switch off everything you do not use in the meantime.
- A site that only shows information (a portfolio, a landing page, a business page): ask whether it needs PHP at all. Plenty of five-page WordPress sites can be exported as a static site, and a static site has no application server to take over.
- Either way: take a full backup before you touch anything, and change your panel and database passwords if your version was exposed.
The same week: "rotate all your secrets"
Unrelated to PHP, that same week Railway, a deployment platform, asked every user to rotate their environment variables, API keys and credentials after unauthorized access to where they were stored. According to its own disclosure, the decrypted contents of some of them were taken, and it paused deployments while it contained the incident.
And according to its status page, almost fifteen hours passed between detecting it and notifying customers. Containing an incident properly takes time, and it is not our place to judge how they handled it. But the number leaves a question that applies to every platform, yours included:
No system is invulnerable. What you do choose is how much you expose, and how fast you find out when something goes wrong. If you keep keys on a platform, know how to rotate all of them in one afternoon: one day you will be asked to. Here is which keys matter and how to rotate them.
What FluentOps does, and what it does not
FluentOps does not run PHP: not the platform, not what you publish on it. A PHP project does not build. So PHP2Shell in particular has no way in. But the lesson of the week is broader than one flaw, so here is what we do in general:
- Your secrets are stored encrypted (AES-256-GCM) and travel encrypted. Always.
- Every deploy is checked before it ships: keys written into the code,
.envand credential files, exposed source (*source maps*, the.gitfolder) and dependencies with known flaws..envfiles and READMEs are not published; the rest is flagged with the file it is in. - Every site is watched. If a published site starts serving a sensitive file, we email you with what to fix. The check is periodic, not instant: we would rather say so than promise you an "immediately" that is not true.
- Whoever comes knocking gets blocked at the edge, before reaching your site: scans looking for
/.env,/wp-login.phpor/.git/configare cut off automatically, with an expiry.
None of that replaces keeping your own backup or using a different password for every service. But it does take off your list what nobody should have to check by hand on the morning the news breaks.