# PHP2Shell: the critical PHP vulnerability every website owner should know about

- Link: https://eprefix.co.uk/php2shell-php-vulnerability/
- Published: 2026-11-06T14:00:00+00:00
- Author: jameszxr

On 21 October 2026 the PHP project released an emergency security update for two
critical vulnerabilities in PHP itself. Together they’ve become known as **PHP2Shell**.
They let an attacker take control of a web server by sending it specially crafted
requests, with no login and no help from the website’s own code. Attacks started
before the fix was even public, and they’ve been growing since.

PHP runs WordPress and a large share of the web, so this one matters for almost 
every business website.

## What’s wrong

The two flaws, CVE-2026-109618 and CVE-2026-109619, are memory-handling bugs deep
inside PHP. One is triggered when PHP runs out of memory part-way through setting
up a request. The other leaves leftover data from one request pointing at memory
that a later request can reuse. Chained together, they give an attacker _remote 
code execution_: the ability to run their own commands on the server.

PHP rates both at 9.2 out of 10 for severity. Every PHP installation that serves
web pages is at risk, whichever way it’s set up, and researchers have shown working
attacks against WordPress, Drupal, Joomla and Magento sites.

## Is it being exploited?

Yes. Amazon’s security team saw the first attempts on 17 October, four days before
the fix was released, and by 28 October was reporting broad exploitation attempts.
On 26 October the US Cybersecurity and Infrastructure Security Agency (CISA) added
both flaws to its list of known exploited vulnerabilities, which it reserves for
flaws that are being used in real attacks.

## Which versions are fixed

The fix is in these releases, or anything newer:

 * **PHP 8.5.12**
 * **PHP 8.4.27**
 * **PHP 8.3.36**
 * **PHP 8.2.35**

There are no official releases for PHP 8.1 or older. The PHP team published source
code patches for 7.4 to 8.1, but versions before that get nothing, and the vulnerable
code goes back as far as PHP 5.4. If your site is still on an old version, this 
is the clearest reason yet to move. PHP 8.2 itself [reaches end of life on 31 December](https://eprefix.co.uk/php-8-2-end-of-life/),
so the next flaw like this won’t be fixed for it at all.

## What to do

 * **Update PHP.** PHP says updating is the only complete fix. Configuration changes
   reduce the risk but don’t make a server safe.
 * **Restart PHP afterwards.** Installing the update doesn’t patch PHP processes
   that are already running. PHP-FPM, Apache or whatever runs PHP on the server 
   needs restarting before the fix takes effect.
 * **Check the version.** In WordPress, go to _Tools > Site Health > Info > Server_
   to see which PHP version the site is running. Make sure it’s one of the versions
   above or newer.
 * **Ask your host.** On shared or managed hosting, the host controls PHP. Ask them
   to confirm, in writing, that your server has the patched version.
 * **Look back as far as 17 October.** Attacks began before the fix, so if your 
   server was unpatched, it’s worth checking for unfamiliar admin accounts, files
   you don’t recognise and unexpected changes since then.

A web application firewall such as Cloudflare’s can block known versions of the 
attack, and Cloudflare has added rules for it. That only buys time, though, and 
doesn’t replace updating.

## If we host your website

PHP updates are part of our managed hosting, so you don’t need to update anything
yourself. If your site is hosted elsewhere and you’re not sure whether it’s been
patched, [get in touch](https://eprefix.co.uk/#contact). We’ll check which version
it’s running and help you get it fixed.