On 20 October 2026, the PHP project disclosed two critical security vulnerabilities in the programming language that powers roughly 70% of the world's websites. Within hours, government sites across Europe started going dark. Within a day, Cloudflare had logged millions of attack attempts. The US National Security Agency told organisations to take their sites offline if they couldn't patch immediately.
If you run a WordPress site, this affected you. If you've been meaning to update your hosting for a while but haven't got round to it, this is why it matters. And if your site is hand-coded static HTML, you probably didn't even notice.
what happened
Two vulnerabilities, collectively called PHP2Shell, were found in the core of PHP itself. Not in a plugin. Not in a theme. Not in WordPress. In the actual language that WordPress, and most of the web, is built on. They were rated 9.2 out of 10 for severity by the PHP team. Security firm watchTowr rated them a full 10.
The flaws allowed an attacker to run their own code on any server running an unpatched version of PHP, without needing to log in or authenticate. That's about as bad as it gets in web security.
Amazon later confirmed they had detected exploit attempts four days before the public announcement. Cloudflare's CEO reported thousands of attempts before the disclosure, hundreds of thousands within two hours of it, and millions by the following day. Attackers were ready and waiting.
who went down
In the UK, 32 government services were taken offline as a precaution, including NHS Scotland and the Office for Budget Responsibility. The National Cyber Security Centre issued around 50,000 alerts to organisations.
Across Europe, government sites in France, Denmark, Finland, Germany and the Netherlands went dark, including the Dutch parliament and the Dutch national cyber security agency. Canada took government sites down too. Hospitals, universities and private companies followed.
Most of these sites weren't hacked. They were taken offline deliberately while security teams scrambled to apply updates. But the disruption was real, and for any business that depends on its website to take bookings, answer enquiries or process orders, even a few hours offline costs money.
why wordpress sites were exposed
WordPress itself wasn't the vulnerability. PHP was. But WordPress runs on PHP. Every single page view on a WordPress site executes PHP code on the server. The admin panel runs PHP. Every plugin runs PHP. Every theme runs PHP. The login page, the contact form, the blog, the shop, all of it.
That means every WordPress site was running the vulnerable code, all the time, on every request. The attack surface is enormous.
A scan by security firm BranDefense found that 59% of sites they checked were still running unpatched PHP versions after the fix was released. If your hosting provider hasn't updated PHP on your server, your WordPress site is still vulnerable right now.
If you run a WordPress site and you're not sure whether your hosting provider has patched PHP, ask them. Today. Don't assume it's been done.
why static html sites weren't affected
A static HTML website is a collection of files. HTML, CSS, images. When someone visits the page, the server sends the file. That's it. No code executes. No database queries. No PHP processing. The server is a filing cabinet, not a computer.
PHP2Shell exploits a flaw in how PHP processes requests. If there's no PHP processing happening, there's nothing to exploit. A static site doesn't care what version of PHP is installed on the server because it never uses it.
Every site I build for my clients is hand-coded static HTML. No WordPress. No content management system. No PHP rendering every page. When PHP2Shell hit, my clients' sites carried on as normal. No patches to rush. No downtime. No panic emails from hosting providers.
the honest bit
I should be upfront about one thing. My sites do use a small amount of PHP for contact forms. When someone fills in a form and hits send, a PHP script handles the email. That's the only PHP on the entire site. One file, doing one job.
That's a different world from WordPress, where PHP handles every page view, every admin login, every plugin, every database call, every image resize, every search, every comment. The difference in attack surface between a single contact form handler and a full WordPress installation with thirty plugins is like the difference between a letterbox and an open front door.
My hosting provider patched PHP within hours of the disclosure, so even that one file was covered. But the point stands: the less code running on your server, the less there is to go wrong.
what this means if you run a small business
If your website runs on WordPress, you're dependent on three things staying up to date: WordPress itself, your plugins, and the PHP version on your server. You don't control the last one. Your hosting provider does. And if they're slow to patch, you're exposed to exactly this kind of vulnerability with no way to fix it yourself.
If your website is static HTML, none of that applies. Your site is files on a server. It doesn't execute code. It doesn't have a login page for attackers to target. It doesn't have a database to steal. It just works.
That doesn't mean WordPress is always wrong. It's a good platform for sites that genuinely need a content management system, like large blogs, online shops, or sites with multiple editors. But for a small business that needs a professional website with a few pages, a contact form, and maybe a booking link, WordPress is overkill, and overkill comes with risk.
the week in numbers
- 70% of websites worldwide run on PHP
- 9.2 / 10 severity rating (watchTowr said 10)
- 32 UK government services taken offline
- 50,000 alerts issued by the NCSC
- Millions of exploit attempts logged by Cloudflare within 24 hours
- 59% of scanned sites still running unpatched PHP after the fix was released
- 0 of my clients' sites affected