PHP2Shell: what the critical PHP flaws mean for your website

If your website runs on WordPress, or on almost any other common content management system, it runs on PHP. On 21 October 2026 the PHP project released emergency updates for two critical flaws that can let an attacker run their own code on the web server, with no password and no account. Security researchers have nicknamed them PHP2Shell.

The release was rushed. Details leaked online the day before the fix was due, along with a tool to exploit one of them, so attackers had a head start on most website owners. If you're responsible for a website, a customer portal or an internal web app, this is the week to find out what version of PHP it runs and who is updating it.

What PHP2Shell is

PHP2Shell is two bugs, both rated 9.2 out of 10 (CVSS 4.0) by the PHP project:

• CVE-2026-109618, "RCE via OOM corruption". When PHP runs out of memory partway through handling a request, it can bail out while its internal request data is only half set up. The clean-up code then treats that half-built data as real.
• CVE-2026-109619, "RCE via stale global state". Internal state that belongs to one request can survive after its memory has been freed, and the next request handled by the same PHP worker can use it before it's reset.

In plain terms, an attacker sends requests designed to push PHP into those error paths, then uses the corrupted memory to run commands on the server. PHP says the risk is highest for Apache's mod_php, where a demonstrated exploit fires before any of your website's own code runs. That matters: a well-written, fully patched WordPress install doesn't protect you, because the hole is underneath it.

Is it being exploited?

As of 26 October, the picture is mixed:

• A proof-of-concept tool called "PHP2Shell" leaked on 20 October, before patches existed.
• watchTowr, a security research firm, says it has seen both flaws exploited against its honeypots (decoy servers) since 21 October.
• Canada's Cyber Centre, in its alert updated on 23 October, says no active exploitation of real organisations had been identified at that point.
• Palo Alto Networks' Unit 42 retracted an earlier report of an attack, saying it could not confirm PHP2Shell was the way in.
• Neither CVE was in CISA's Known Exploited Vulnerabilities catalogue as of its 23 October update.

The UK's National Cyber Security Centre went further than most and told organisations to consider taking systems offline if they can't update or mitigate in time. With a public exploit tool, and Unit 42 counting more than 22 million exposed PHP instances online, we'd treat this as something attackers will use, not something they might.

Are you affected?

Every PHP installation that serves web requests is in scope, including APIs and other endpoints that don't return a page: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The fixed versions are:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Anything earlier on those branches is vulnerable. PHP 8.1 and older no longer get updates from the PHP project. Some Linux distributions and long-term support vendors have backported the fix, and the PHP team published minimal source patches for 7.4, 8.0 and 8.1, but if your site runs an old branch the honest answer is that it needs upgrading.

To check a WordPress site, sign in and open Tools, then Site Health, then Info, then Server: the PHP version is listed there. On cPanel hosting it's under Select PHP Version or MultiPHP Manager. Don't forget the less obvious places PHP lives: staging copies of your site, old microsites nobody updates, intranet tools, and appliances or products that bundle PHP inside them.

If a hosting company or agency looks after your site, the version you see may not tell you whether they've applied their own patched build. Ask them directly.

How to fix it

1. List every site and app that runs PHP, with who hosts it and who is responsible for updating it.
2. Update to a fixed version. On managed or shared hosting that's usually your host's job: email them today and ask for written confirmation that PHP on your account is on a fixed release or a vendor build that includes the fix. On your own servers, install your distribution's updated packages or the PHP release, then restart every PHP worker. PHP-FPM pools and Apache keep the old code in memory until they restart.
3. Move old sites off unsupported PHP. A site still on PHP 7.4 or 8.0 has bigger problems than this week's bug. Plan the upgrade now; your developer will need to test themes and plugins against the newer version.
4. If you can't update straight away, reduce the exposure. PHP lists these as stopgaps that block specific attack paths but don't make an installation safe: - Set memory_limit=-1 in a place applications can't override (for example php_admin_value in the FPM pool), and set a low post_max_size, such as 8M if the site takes no uploads. - Set session.upload_progress.enabled=0 in php.ini or the FPM pool, not with ini_set() or .user.ini, then restart every worker. PHP also recommends this setting until its next regular release, for a related, less likely issue (CVE-2026-115560) it disclosed on 23 October. - On PHP 8.5, set fatal_error_backtraces=0.
5. For anything you can't fix or mitigate, follow the NCSC's advice: take it off the internet until you can.

If you think it already happened

A successful attack runs commands as the web server's account, so look for what that account did:

• New or changed PHP files in the website folders, especially in upload directories. Attackers usually leave a "web shell" so they can get back in.
• New administrator accounts in WordPress or your CMS, and new scheduled tasks on the server.
• Commands such as sh, bash, curl or wget started by the web server or PHP-FPM process, and outbound connections from the web server to addresses you don't recognise.
• Web server logs showing very large or malformed requests around the time of any changes.

If you find signs of a compromise, isolate the server, keep the logs, and assume any passwords or keys stored on it are known to the attacker. Report it to ASD's ACSC at cyber.gov.au (opens in a new tab). Most businesses choose "Cybercrime", which covers hacked devices, systems and accounts; "Cyber security incident" is only for organisations with 250 or more staff or $250 million turnover, government departments, critical infrastructure and regulated entities. Or call the Australian Cyber Security Hotline on 1300 CYBER1 (1300 292 371), 24 hours a day. If customer or staff personal information could have been accessed, you may have obligations under the Notifiable Data Breaches scheme.

Where Geidi fits

Geidi's cyber security services are aligned to the Essential Eight, ISO/IEC 27001 and SMB1001, and backed by a 24/7 security operations centre. If you're not sure what your website runs on, or who is meant to be patching it, get in touch.

Sources

• PHP: Security advisory: Critical remote code execution vulnerabilities, update now (21 October 2026) (opens in a new tab)
• PHP: Informational advisory: Session upload progress (23 October 2026) (opens in a new tab)
• PHP: GHSA-w8hw-w9fx-j79w, RCE via OOM corruption (CVE-2026-109618) (opens in a new tab)
• PHP: GHSA-6wmf-4rv5-p3rp, RCE via stale global state (CVE-2026-109619) (opens in a new tab)
• UK National Cyber Security Centre: Critical security issue affecting PHP (opens in a new tab)
• Canadian Centre for Cyber Security: AL26-026, Critical vulnerabilities impacting PHP (updated 23 October 2026) (opens in a new tab)
• watchTowr: PHP remote code execution ("PHP2Shell") (opens in a new tab)
• Palo Alto Networks Unit 42: Threat Brief: Critical vulnerabilities in PHP (updated 25 October 2026) (opens in a new tab)
• CISA: Known Exploited Vulnerabilities catalogue (opens in a new tab)
• ASD's ACSC: Submit a report (opens in a new tab)
• OAIC: About the Notifiable Data Breaches scheme (opens in a new tab)