PHP2Shell: what the PHP vulnerability means for your website

On 21 October 2026, PHP released emergency updates for two critical vulnerabilities, together called PHP2Shell. If your website runs on PHP, this affects you. And most websites do: WordPress, WooCommerce, Joomla, Laravel and most custom sites all run on it.

The good news: the hole has been closed. The less good news: abuse was reported before the fix was out, and a lot of websites run on a PHP version that will never get a fix. In this article you'll read what is going on, which versions are safe, how to tell whether your site was hit and what to do then.

What is going on

PHP2Shell consists of two vulnerabilities, known as CVE-2026-109618 and CVE-2026-109619. Both scored 9.2 out of 10, which in practice means: close them as soon as possible.

The problem is not in WordPress, a theme or a plugin, but in PHP itself. It concerns the way PHP handles memory when a request fails halfway. An attacker can provoke that with a deliberately broken request. If it works, they can run their own code on the server, read data that isn't meant for them or take the website down.

Before the fix appeared, code to abuse one of the vulnerabilities was already circulating, and security researchers saw attempts in the wild. So this is not a theoretical risk.

Which PHP versions are safe

Every version from before the fix is vulnerable, going back a long way. These are the versions in which the hole is closed:

That last row matters most. PHP 8.1 and older no longer receive security updates from PHP. A website running on them stays vulnerable, to this flaw and to every one after it.

One nuance: some hosting providers put the fix into the version you already run without changing the version number. If your site still shows 8.5.11, that isn't necessarily wrong. In that case, ask your hosting provider whether the 21 October fix is in your PHP.

How to tell your site was hit

An attack doesn't always leave traces you see straight away. Watch for these signs, especially if your site ran on a vulnerable version in recent weeks:

• Visitors get redirected to spam, gambling or fake shops, often only when coming from Google or on a phone.
• There are administrators or users in your CMS you don't recognise.
• Files show up that you don't recognise, especially PHP files among your images or uploads.
• Your website suddenly gets slow or your hosting reports much higher usage.
• Your domain sends emails you didn't send, or your emails end up in spam.
• Google shows a warning on your site, or Search Console reports a security issue.
• Your antivirus or browser blocks your own website.

If you see any of these, assume someone was inside, even if everything looks normal again at first glance.

What to do if your site was hit

Panic doesn't help, order does. This is the order I follow myself:

1. Get the hole closed first. As long as the vulnerable version runs, the same attack can happen again tomorrow. Cleaning up without updating is mopping with the tap running.
2. Keep a copy of how things are now. Before you remove anything: a full copy of files and database, so you can find out later what happened.
3. Change all passwords and keys. Hosting, FTP or SFTP, database, email, every administrator in your CMS, and API keys for payment providers or other integrations. The flaw allows reading data from memory, so assume whatever was in your configuration has been seen.
4. Clean up thoroughly. Remove unknown users and files, and reinstall the core of your CMS, your theme and plugins from a clean source. Restoring a backup from before the attack works too, but only once the hole is closed.
5. Check what changed outside your files. Scheduled tasks, redirects, DNS records and email settings are often changed to get back in later.
6. Ask Google for a new review. If your site had a warning, request a review in Search Console once everything is clean.
7. Think of your customers. If the attacker could see personal data, such as orders, accounts or form submissions, you must report it as a data breach within 72 hours: in Belgium to the Data Protection Authority, in the Netherlands to the Dutch Data Protection Authority.

Not sure whether your site was hit? Then treat it as if it was. Changing passwords takes fifteen minutes; an attacker who stays unnoticed for months costs a lot more.

Why so many websites stay stuck on an old PHP version

If updating matters this much, why do so many sites still run on PHP 8.1 or older? Usually not out of unwillingness. An old site breaks on a newer PHP version: a plugin that hasn't been updated in years, a theme from a maker who stopped, or custom code written for a version from ten years ago. So the version stays put, until a flaw like this comes along.

That is where the real risk lies. Not this one flaw, but a website that can no longer keep up. PHP 8.2 gets fixes until 31 December 2026. If your site runs on it, now is the moment to plan, not in January.

How I can help

I've worked with PHP since 2006 and build my own sites on the latest version. If your site was hit or is stuck on an old version, I can help in three ways:

• Raising your PHP version. I first test your site on a test environment with the new version, fix what breaks and only switch over once everything works. No surprises on your live site.
• Cleaning up after an attack. I find out what happened, clean up, change what needs changing and tighten security. A security round costs €300, one-off.
• Rewriting your site. If your site is held together by outdated plugins or code nobody understands anymore, I rebuild it in light, modern PHP. Faster, safer and ready for the years ahead, with the same texts and addresses so you keep your place in Google.

Don't want to lie awake over the next flaw? With maintenance at €50 per month I keep your PHP version, software and backups up to date, and you hear from me before you read about it in the news.

Not sure whether your site is safe? Send me a message with your website's address. I'll check it for free and tell you honestly whether anything needs to happen.