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, 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. We’ll check which version it’s running and help you get it fixed.
