EN
Something unusual happened this week. Government websites in several countries went dark on purpose. Finland took public services offline, the Netherlands switched off its digital ID system and its parliament site, and Wikipedia and the BBC pulled parts of their sites. Security agencies in the UK, the EU, the US and Australia told organizations the same thing: if you cannot patch right now, consider switching the site off until you can. Institutions that measure downtime in lost revenue decided that going offline for a few hours was the safer bet.
The cause is a pair of flaws in PHP, the backend language that quietly runs most of the web. Roughly three out of four websites with a server-side language use PHP, and the researchers who found the flaws estimate that around 70% of the web was affected. WordPress alone powers over 40% of all sites, and every one of them runs on PHP. So do Drupal, Joomla, Craft CMS, Magento and every Laravel application. The flaws have a name, PHP2Shell, and if your website is built on any of those platforms, this post is for you. We have kept it free of jargon on purpose.
What PHP2Shell actually is
Think of PHP as the engine under your website's hood. WordPress, Drupal and the rest are the car built around that engine. On October 21, the PHP team published emergency fixes for two bugs in the engine itself. Together they allow someone on the internet to send a single, specially crafted request to your site and run their own code on your server. No password, no login, no clever trick with a plugin. The attack happens before your website even wakes up to answer the request.
That is why keeping WordPress, your theme and your plugins up to date does not help here. All of that sits on top of the engine. If the engine is unpatched, the site is exposed no matter how tidy everything above it looks.
The timeline made it worse. The technical details leaked a day before the fix was ready, and attacks were observed within hours. A working exploit tool is now public, which means automated scanners are sweeping the internet looking for any server that answers in PHP.
What happens if you ignore it
This is not a theoretical risk, so let's be specific about the consequences.
An attacker who gets in can install a hidden backdoor, read your database, and walk away with customer records, form submissions and the passwords stored in your site's configuration. They can quietly inject spam links or malware into your pages, which gets your domain flagged by Google and blocked by browsers. They can deface the site, or hold it for ransom. The second flaw also leaks memory from the server, which can expose session tokens, API keys and security certificates belonging to other visitors and systems.
Cleaning up after any of that means restoring from a backup you hope is clean, rotating every credential the site ever touched, and explaining to customers and partners what happened. For a regulated business, that conversation involves lawyers.
The five steps to get out of this safely
The good news is that the fix exists and, for most sites, it is quick. Here is what to do, in order.
1. Find out who controls your PHP version. If your site lives on a managed host such as WP Engine, Flywheel, Pantheon, Pagely, SiteGround or WordPress VIP, the host updates PHP for you, and most of them completed the rollout within a day. If your site lives on a server your company or your IT provider administers, nobody will do this for you. That server needs a manual update now.
2. Confirm the version, do not assume it. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything older on those branches is vulnerable. If your site is still on PHP 8.1, 8.0 or 7.x, there is no official fix at all. Those versions have been unsupported for years, and the only real answer is to upgrade to 8.3 or newer. Your host's control panel, or your site's health screen, will show the exact number.
3. Check for signs of a break-in. Even a patched server may have been visited during the window between the leak and the fix. Look for user accounts you do not recognize, new files in your uploads folder, scheduled tasks you did not create, plugins you did not install, and unexplained errors in the server logs since October 20.
4. Rotate the keys. Change the admin passwords, the FTP and SSH credentials, and any API keys stored in the site's configuration. If the site was exposed, assume those were read.
5. Reduce what the internet can see. Hide the PHP version from your server's responses so scanners cannot tell at a glance whether you are an easy target. If your site uses a headless setup, where the public pages are static and the CMS sits behind them, restrict who can reach that CMS. Your visitors never needed access to it in the first place.
A note on headless and static sites
Many of the sites we build run as static front ends on platforms like Vercel or Netlify, with the content system behind them. During this week's scramble, those public sites stayed up. The content system behind them still had to be patched, because it is still a PHP server, but it could be locked down or taken offline without visitors noticing anything. That difference, between a site that goes dark and a site that keeps working while you fix things, is the strongest argument we have seen in years for that architecture. It is worth a conversation if your site is not built that way today.
We are here to help
We have spent this week checking every site we built or maintain, confirming patch status with hosts, and walking our clients through the steps above. If you are a partner or client of Assemble and you are not sure where your site stands, reach out. We can run the diagnosis, confirm the fix landed, review the site for signs of compromise and, where we have access, apply the updates ourselves.
And if you are not a client yet but this post made you nervous, that is a reasonable reaction. Get in touch and we will help you find out, quickly and without drama.