The PHP flaw of 21 October: the question is not whether your site runs PHP, but who installed the update
DigiD, MijnOverheid and the Dutch parliament took their sites offline as a precaution. The flaw sits in PHP itself, the language most of the web runs on. The update is out. The question that matters for your site: who installed it, and did they know it was their job?
On 21 October, DigiD, MijnOverheid and the website of the Dutch House of Representatives went dark in the middle of the day. Not an outage, not a hack: a precaution. There was a critical flaw in PHP, and the fix would only arrive that afternoon.
PHP is the programming language under most of the web. WordPress runs on it, and so do Drupal, Joomla and Magento. So there is a good chance your website runs on it too, or that you are not sure.
This piece is not about how the flaw works. It is about the question it raised for every business owner with a website: am I exposed, and who actually takes care of this for me?
Two flaws in PHP itself, and an afternoon without DigiD
These were two critical flaws in PHP itself, not in a plugin or a theme. They were rated 9.2 out of 10 for severity. Through them an attacker can run code on your server without logging in. Presumably every common version from PHP 5 onwards is affected, and PHP 8.1 and older get no official patch.
Proof-of-concept code showing how to abuse the flaws was already public. The Dutch National Cyber Security Centre (NCSC) said temporary workarounds were not enough: only the update helps.
- 11 August The first flaw is reported to the PHP Foundation.
- 24 August Security firm Wiz reports the second.
- 21 October DigiD, MijnOverheid, the House of Representatives, the NCSC, RTL and the Flemish government take sites offline as a precaution.
- 15:07 The NCSC calls on everyone running PHP to install the update.
- 15:43 The update is online, ahead of the announced 16:00.
- 18:11 and 20:27 MijnOverheid, then DigiD, are reachable again.
Does my website run on PHP?
Probably. According to W3Techs, around 70% of websites whose server language is known use PHP. WordPress alone runs about 42% of all websites.
If you have a WordPress site, a shop on WooCommerce or Magento, or a site your agency built "in Drupal" or "in Joomla", it runs PHP. And even without a PHP site of your own you can have it underneath you: security firm Huntress points out that PHP also sits inside many hosting control panels.
Not sure? In your WordPress dashboard, go to Tools, Site Health, the Info tab, and open Server. Your PHP version is listed there. No WordPress: ask your hosting provider, they can tell you in one sentence.
Who installs the update?
This is not a WordPress problem, and not the problem of one hosting provider. It is a maintenance problem: the update exists, but somebody has to install it somewhere. And for a lot of websites, nobody is sure who that is.
They run the server and install PHP updates. One catch: many control panels let you pick a PHP version yourself. If yours is pinned to an old one, that version gets no patch.
Nothing happens on its own. If nobody agreed who looks after the server, nobody does.
No official patch is coming for these versions. Only an upgrade to a newer PHP version helps, and that can break your site if its plugins or theme are old.
That last one is the painful one. A site nobody has touched in years often sits on an old PHP version precisely because an upgrade would break a plugin. That worked fine, until now.
Almost every business owner I talk to knows who built their website. Almost nobody knows who looks after it. You find out on a day like 21 October, and by then it is too late to start asking around.
An update closes the door, but does not check who is already inside
The update closes the flaw. It does not clean up anything someone may have done while it was open. The flaws were reported in August, and proof-of-concept code was circulating. On 21 October the NCSC had not yet seen active abuse, but security firm Sansec reported that Cloudflare was already seeing early attack attempts.
If your server was reachable between the flaw becoming known and the update going in, updating is step one, not the last step. Afterwards, check whether anything changed that you did not change yourself.
What to check today
-
Ask your hosting provider whether PHP was updated, and to which version.
One email or chat. A good host already has the answer ready.
-
Check your PHP version.
In WordPress: Tools, Site Health, Info, Server. If it says 8.1 or lower, you need an upgrade, not just an update.
-
Update your plugins and theme first, then PHP.
A newer PHP version does not work with every old plugin. In that order, the upgrade is far less likely to take your site down.
-
Look for admins or files you do not recognise.
An unknown administrator account, or recently changed files nobody touched, is the moment to have a specialist take a look.
-
Write down who handles it next time.
A name, a phone number, and what your contract says about security updates. That is the answer you wanted on 21 October.
The next flaw will go the same way
According to Wiz, these flaws had been sitting in PHP for more than ten years. And AI makes finding flaws like these faster, for attackers too. So there will be a next one, and it will come sooner.
Then what counts is not what kind of site you have, but whether someone picks it up on the day it matters. That is not a technical question. It is an agreement.
How Growthdesk handles it
Growthdesk sites do not run on PHP. They are built in Astro, an open-source framework that serves pages as ready-made HTML, on Hetzner servers in Germany. There is no CMS underneath, so no plugins and no login screen to keep patched. Changes go through WhatsApp.
That does not make a site invulnerable, and nobody claims it does. The difference is who carries it: a flaw in PHP does not touch these sites, and the next flaw in something else is a job for Growthdesk, not for the client.
So: is your site vulnerable?
If your site runs on PHP and nobody installed the update on or after 21 October, probably yes. If you do not know who should have done that, that is the real problem.
Run through the five checks above today. Then write down who does it next time, because there will be a next time.
Frequently asked questions
Is my website vulnerable to the PHP flaw?
If your site runs on PHP and its PHP version has not been updated since the fix of 21 October, probably yes. Presumably every common version from PHP 5 onwards is affected. Ask your hosting provider whether PHP was updated and to which version, or check in WordPress under Tools, Site Health.
Is WordPress affected by the PHP flaw?
The flaw is not in WordPress but in PHP, the language WordPress runs on. So every WordPress site runs on PHP and depends on the PHP update on its server. A WordPress update on its own does not fix it.
Is installing the update enough?
It closes the flaw, but it does not clean up anything that may have happened while it was open. Proof-of-concept code was circulating, so after updating, look for unknown administrators or recently changed files. If something looks off, have a specialist look at it.
What if my site runs on PHP 8.1 or older?
Then no official patch is coming. Only an upgrade to a newer PHP version helps. Update your plugins and theme first, because old plugins do not always work on a newer PHP version.
Do Growthdesk websites run on PHP?
No. Growthdesk sites are built in Astro and run without PHP, without a CMS and without plugins, on Hetzner servers in Germany. Updates and servers are Growthdesk’s job; changes go through WhatsApp.
Enter a valid website URL (e.g. yourwebsite.com).
