PHP2Shell: what the October 2026 PHP security flaw means for your website

On 21 October 2026 the PHP project released emergency updates for two critical security flaws, now known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). PHP is the programming language that runs most of the web, including every WordPress site, so this affects a lot of small business websites.

This guide explains what's happened in plain English, how to tell if your site is affected, and what to do about it. There's a more technical section at the end for anyone who manages their own server.

What happened

PHP's own team rates both flaws 9.2 out of 10 for severity. In short, they let an attacker run their own code on your web server just by sending it a specially crafted request. They don't need a password, and it happens before WordPress or any of your site's own code even starts.

If that works, the attacker effectively controls your website. They can add spam pages, redirect visitors to scam sites, steal form submissions or customer data, or use your server to attack others.

A few things make this one more urgent than the usual security update:

• Attacks have already started. Amazon's threat researchers recorded an attempt on 17 October, four days before the fix was released. By 21 October they reported the flaw was being "broadly exploited in the wild", and Cloudflare said it was seeing early attacks.
• It goes back a long way. The vulnerable code dates back to PHP 5.4, released in 2012, so older sites are affected too.
• The details leaked early. The flaw identifiers circulated online the day before the fix, and the PHP project brought its release forward by a day as a result.

Is my website affected?

Your site is likely affected if all of these are true:

1. It runs on PHP. This includes WordPress, WooCommerce, Joomla, Drupal, Magento and most sites built by agencies or freelancers before around 2020.
2. Its PHP version is older than the fixed versions below.
3. It's running on a normal web server setup (PHP-FPM, Apache with mod_php, php-cgi, LiteSpeed or FrankenPHP). That's almost all of them.

Sites built on Wix, Squarespace or Shopify don't run PHP that you control, so there's nothing for you to do. Those platforms handle it themselves.

The fixed versions

How to check your PHP version

• Quickest: try my free PHP security check. Enter your web address and it tells you which PHP version your site shows, if it shows one, and whether that version has the fix.
• WordPress: go to Tools → Site Health → Info → Server. It shows the PHP version.
• cPanel or Plesk: look for "Select PHP Version" or "PHP Settings" in your hosting control panel.
• Not sure who hosts your site? That's worth finding out today. Your web designer, or whoever you pay for hosting, will know.

What to do now

If someone else manages your hosting

This is most small businesses. Your job is to make sure it's actually been done:

1. Ask your host or web designer, in writing, whether PHP on your server has been updated to a fixed version, and when. A good host will have done it already or will tell you when it's scheduled.
2. Check which PHP version your site is set to in your control panel. Many shared hosts offer several versions side by side. They'll patch each one, but if your site is set to 7.4 or 8.1, it stays vulnerable until you switch.
3. If you're on 8.1 or older, plan the move to 8.3 or 8.4 now. Take a backup first, then switch the version and check the site. Old plugins or themes can break on newer PHP, which is the usual reason sites are left on old versions in the first place.

If your site is on one of my care plans, this is already in hand. PHP and server updates are part of what you pay for.

If you manage your own server

Update PHP through your package manager, then restart PHP. The update doesn't protect anything until the running processes have been replaced. More detail is in the technical section below.

Check your site hasn't already been hit

Because attacks started before the fix was public, it's worth a quick check even after updating. Updating closes the door, but it won't remove anything an attacker has already left behind. Look for:

• Admin users you don't recognise (in WordPress, under Users).
• Files modified since 17 October that you or your developer didn't change.
• New pages, spam links, or redirects to sites you don't know, especially when visiting from Google on a phone.
• Warnings in Google Search Console, or your host suspending the account.
• A sudden jump in server load or outgoing email.

If anything looks wrong, don't just delete the odd file. Follow my guide on what to do when your website gets hacked, and make sure you have a clean backup from before 17 October.

Need a hand with this?

If you're not sure whether your site is affected, can't work out who hosts it, or you're stuck on an old PHP version because something breaks when you update, get in touch. I can check which PHP version your site is running, update it safely, fix any plugins or themes that fall over on a newer version, and look for signs it's been tampered with.

You don't need to be an existing client. Email me at hello@webcardiff.co.uk with your website address, and I usually reply within about an hour during the working day.

Technical notes for anyone running their own server

The two flaws:

• CVE-2026-109618: out-of-memory handling can interrupt PHP while internal request data is only partly set up. Request cleanup then treats the invalid data as valid.
• CVE-2026-109619: request state can outlive the memory behind it (a use-after-free), so a later request handled by the same worker may use stale state. PHP's advisory also confirms memory disclosure.

Affected setups are PHP-FPM, Apache with mod_php (rated the highest risk), php-cgi, FrankenPHP and LiteSpeed.

Updating:

• Check both the CLI and FPM versions, as they can differ: php -v and php-fpm8.3 -v (swap in your version). ls /etc/php lists every version installed.
• On Debian and Ubuntu with the Ondřej Surý packages: sudo apt update && sudo apt install --only-upgrade 'php8.3*'. Repeat for every installed PHP version, including ones no site currently uses.
• If your distribution backports security fixes, the version number may not change. Look for the CVE numbers in the package changelog instead.
• At the time of writing, the Remi repository for RHEL-based systems hadn't published updated packages. Use your distribution's packages or build from source.
• Restart afterwards. Restart PHP-FPM, and Apache too if you use mod_php. Long-running PHP processes such as queue workers, Laravel Horizon, Octane or Reverb keep the old code in memory until they're restarted. Rebuild any Docker images that bundle PHP.

If you can't patch straight away, these settings reduce the risk. They don't remove it, so they're a stopgap until you update:

• memory_limit=-1, set so applications can't override it (for CVE-2026-109618).
• session.upload_progress.enabled=0 (for CVE-2026-109619). On PHP 8.5, also fatal_error_backtraces=0.
• Apply both together, as each covers a different flaw, then restart every PHP worker.
• If the site doesn't need file uploads, block multipart/form-data POST requests before they reach PHP, and keep post_max_size low.
• Cloudflare has added firewall rules for the known attack patterns on all plans, including free. Cloudflare itself calls these a stopgap, and they only protect traffic that actually goes through Cloudflare.

For the full detail, see the PHP 8.x changelog and Tenable's PHP2Shell FAQ.