PHP2Shell explained: what the October 2026 PHP flaws mean for your website

In short: on 21 October 2026, the people who maintain PHP released emergency fixes for two critical security flaws, nicknamed PHP2Shell. On a server that hasn't been updated, an attacker can run their own code without logging in, which can mean taking over the whole website. Attackers started trying it within days. If your website runs on WordPress, WooCommerce, Laravel or anything else built with PHP, make sure the server's PHP has been updated. This guide explains what happened, how to check, and what we did for the sites we look after.

What is PHP, and why should you care?

PHP is the programming language that runs on a web server and builds your pages when someone visits. WordPress and WooCommerce are written in PHP, and so are Laravel apps, Drupal and Joomla sites and many custom-built websites. You may never see it, but if your site is one of these, PHP is quietly working behind every page view and every form someone sends.

That's why a flaw in PHP itself is serious: it doesn't matter how carefully the website on top was built. The weakness is in the engine underneath. For the same reason, updating WordPress, your theme or your plugins does not fix it. The PHP software on the server has to be updated.

What happened, in plain English

Security researchers found two separate flaws, now tracked as CVE-2026-109618 and CVE-2026-109619. PHP rates both 9.2 out of 10 for severity. Both can let someone who isn't logged in make the server run their own code. In security terms that's "remote code execution", and it's about as bad as website flaws get.

Flaw 1: the half-finished form (CVE-2026-109618)

Imagine a receptionist who runs out of paper halfway through filling in your visitor form, and instead of starting again, files the half-finished form as if it were complete. When PHP runs out of memory while it's setting up an incoming request, it can leave that request's data only partly built, and then carry on as if it were valid. An attacker can deliberately cause that moment and use the gaps.

Flaw 2: the room that wasn't cleaned (CVE-2026-109619)

Imagine a hotel room that isn't fully cleaned between guests, so something the last guest left behind is still there when the next one checks in. PHP can keep a little information from one request after it has thrown away the memory behind it. An attacker sends one request to leave something behind, then a second request that makes PHP use it.

How an attack works

1. 01

   A crafted request

   The attacker sends a specially built request to your website, the same way any visitor's browser would. No login is needed.

2. 02

   PHP gets confused

   The request pushes PHP into one of the two faulty situations: a half-built request, or leftovers from an earlier one.

3. 03

   The attacker's code runs

   The server runs the attacker's instructions. From there they could change pages, steal data or plant malware.

How it unfolded

The out-of-memory problem was first spotted by a PHP developer in 2024, but there was no agreement on how to fix it. Researchers found it again this year, and things moved quickly in October:

Timeline, 2026

1. August

   Security researchers find the flaws again, and PHP starts preparing fixes.

2. 17 October

   Amazon's security team records an attempt to exploit the flaw, before any fix exists.

3. 20 October

   Details leak online a day before the planned announcement. PHP confirms fixes are coming.

4. 21 October

   PHP releases fixed versions. Security firms report attackers actively trying the flaws the same day.

5. 23 October

   PHP warns of a third, much narrower issue (CVE-2026-115560), with a fix to follow.

At the time of writing, security firms have seen plenty of attempts, including automated attacks trying to recruit servers into botnets, but none of the reports we've read confirms a successful break-in. That can change quickly, and the safest assumption is that any unpatched PHP site will be tried.

Is my website affected?

Almost every website that runs PHP to serve its pages is in scope, whatever the hosting setup. The quickest way to find out where you stand:

Is my site affected?

1. Does your website run on PHP?

WordPress, WooCommerce, Laravel, Drupal, Joomla, Magento and many custom sites do. Not sure? Ask your developer or host.

No

Sites on Shopify, Wix, Squarespace or Webflow's own hosting, and sites like this one (built with Next.js), don't run PHP for you, so there's nothing for you to patch.

Yes, or not sure

2. Has the server's PHP been updated since 21 October?

Ask your host or developer, using the message below.

Yes

You're protected against PHP2Shell. It's still worth asking for a check of the logs from 17 October onwards.

No, or no answer

Treat the site as at risk. Ask for PHP to be updated today, then for the logs to be checked.

Which PHP versions are safe?

PHP comes in "branches" (8.2, 8.3 and so on). Each supported branch got a fixed release on 21 October. If your site is on an older branch, there's no official fixed release, and the right move is to upgrade.

Your PHP branch	Safe from version	What to do
8.5	8.5.12	Update
8.4	8.4.27	Update
8.3	8.3.36	Update
8.2	8.2.35	Update, and plan a move to 8.3 or newer: 8.2 stops getting security fixes on 31 December 2026
8.1, 8.0, 7.4	No official release	Upgrade to a supported branch (8.3 or newer). Only source-code patches exist
7.3 and older	No fix	Upgrade as a priority

One catch: Linux distributions such as Ubuntu, Debian and Red Hat often apply the fix without changing the main version number. So "PHP 8.3.6" on an Ubuntu server may already be patched. Your host or developer can confirm this from the package's changelog, which will mention the CVE numbers.

What to do now: a checklist for website owners

1. Find out what your site runs on. If it's WordPress, WooCommerce, Laravel or another PHP system, carry on.
2. Ask your host or developer to confirm PHP is updated. Not WordPress or plugins: PHP itself.
3. If your site is on PHP 8.1 or older, plan an upgrade now. Older plugins can break on newer PHP, so it should be tested first, but it can't wait.
4. Ask for a check of the logs from 17 October onwards for signs of attack: unexpected new files, new admin users or unusual errors.
5. Make sure you have a recent, working backup stored away from the server, so you can recover if the worst happens.

Not sure what to ask? You can copy this:

"Hi, could you confirm that the PHP on the server for [your website] has been updated to fix the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619)? Please tell me which PHP version it's running now, and whether the logs since 17 October show any signs of attack. Thank you."

On managed WordPress hosting, the host usually updates PHP for you, but it's worth getting a clear yes rather than assuming. If your host can't or won't answer, that tells you something too.

If you manage your own server

This part is for developers and anyone who looks after a server themselves.

• Check the PHP that serves web requests, not just the command line. php -v can show a different version from the one PHP-FPM, Apache's mod_php, php-cgi, LiteSpeed or FrankenPHP actually uses. All of them are affected, and PHP rates mod_php highest risk. Check a phpinfo() page (then delete it) or the PHP-FPM binary's version.
• Update, then restart. Install the fixed packages or rebuild your Docker images, then restart PHP-FPM or Apache. Running workers keep the old code until they restart.
• Check memory settings afterwards. The fix adds a hard memory limit: a request that hits it now ends the process outright. Review memory_limit and post_max_size so normal uploads still work.
• If you can't update today, PHP says no setting fully protects you, but some steps reduce the risk while you arrange it:
  • Turn off session.upload_progress.enabled in php.ini or your PHP-FPM pool, then restart. It doesn't work from ini_set() or .user.ini. This reduces exposure to the second flaw only.
  • Limit request sizes at your proxy or firewall.
  • If you use Cloudflare, check that its managed firewall rules are turned on. Cloudflare added rules for these flaws on 21 October.
  The UK's National Cyber Security Centre has advised considering taking systems offline if they can't be patched.
• Look for signs of compromise. Look for:
  • unusually large or deeply nested form uploads
  • PHP workers crashing or hitting memory limits
  • bursts of 500 errors
  • oversized session cookies
  • new files in the web root (especially PHP files)
  • new cron jobs or user accounts
  • PHP processes making unexpected outbound connections
  Save the logs before changing anything.

The third issue: CVE-2026-115560

On 23 October, PHP described a third, separate problem in how sessions are handled. It only affects applications set up in an unusual way, involving a non-default session setting that the application changes while it runs, and PHP considers it unlikely to affect most sites. There's no fix yet; it will come in the next regular PHP release. Turning off session.upload_progress.enabled also helps here. We'll update this post when the fix is out.

What we did at Renav

As soon as the fixes were released, we went through every website we're responsible for. This website, renav.co.uk, is built with Next.js and doesn't run PHP, so it wasn't affected. The client WordPress, WooCommerce and Laravel sites we host and manage do run PHP.

Our response

15 sites in 24 hours

• 01Checked every PHP site we look after: which PHP version each one runs, and where it's hosted.
• 02Patched our own servers to the fixed PHP versions and restarted PHP.
• 03Asked each managed host to confirm they had updated PHP for the client sites they run.
• 04Checked the logs from 17 October onwards for signs of attack.

Within 24 hours, we had worked through all 15 PHP sites we host and manage, following those four steps. We'll keep watching for the fix to the third issue and apply it when it's released.

Not sure about your website?

If you don't know what your website runs on, who hosts it or whether it has been updated, you're not alone, and you don't need to work it out yourself. Send us your website's address and we'll check whether it's affected and tell you, in plain English, what needs doing. If it needs fixing, we'll give you a fixed price first.

Sources

This post is based on PHP's own security announcements and reports from security researchers. Facts are correct as of 24 October 2026; check php.net for the latest.

• PHP: 2026 news and security releases
• watchTowr: PHP2Shell FAQ
• Qualys: PHP2Shell, find, mitigate and patch
• Huntress: Rapid response to PHP2Shell
• Help Net Security: PHP2Shell patched
• The Hacker News: Emergency patches for two PHP2Shell flaws
• The Hacker News: PHP warns of another issue (CVE-2026-115560)