php2shell: critical PHP vulnerabilities and what to do now

On 21 October 2026 (UTC), the PHP project released emergency security updates for two critical vulnerabilities, nicknamed “php2shell”. In eastern Australia the release landed in the early hours of 22 October. Both flaws can allow unauthenticated remote code execution: someone who can send web requests to a vulnerable server may be able to run their own code on it without logging in. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you run anything built on PHP, update it now.

PHP sits underneath WordPress, Drupal, Joomla and Magento, and under many portals, intranets and business applications that never mention what they are built on. Patching and hardening are part of our cybersecurity and website management work. This article draws on the PHP project’s security advisory, the critical alert from ASD’s Australian Cyber Security Centre (ACSC), CERT-EU advisory 2026-018 and the CISA alert of 21 October, and covers who is affected, how to check your servers and what to do if you cannot patch today.

What was announced

CVE-2026-109618, remote code execution via out-of-memory corruption. If PHP runs out of memory while it is still reading a request, such as a file upload, request cleanup can treat partially initialised data as valid.
CVE-2026-109619, remote code execution via stale global state. Internal state from one request can survive after its memory has been freed, and a later request handled by the same worker may use it before it is reset.

PHP rates both 9.2 (Critical) on CVSS v4.0. An advance notice went out on 20 October, and the release was brought forward a day after the CVE identifiers circulated publicly. The PHP Foundation credited researchers at Calif, OpenAI and Wiz, among others.

Who is affected

The PHP project says every installation that serves web requests is at risk, including:

PHP-FPM, the usual way PHP runs behind Nginx and many Apache servers.
Apache with mod_php, which PHP considers the highest risk. It has a demonstrated exploit where one unauthenticated request triggers the attack before any application code runs.
php-cgi, FrankenPHP and LiteSpeed.

By version:

PHP 8.5, 8.4, 8.3 and 8.2: fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.2 reaches end of life on 31 December 2026.
PHP 7.4, 8.0 and 8.1: no official release. The PHP security team published minimal source backports, and some Linux distributions and long-term support vendors provide patched packages.
Older than PHP 7.4: no fix from the PHP project. Researchers trace the affected code back as far as PHP 5.4.

The flaw is in PHP itself, so updating WordPress, its plugins or your CMS does not fix it. The PHP runtime underneath has to be updated.

What ASD’s ACSC says

ASD’s ACSC published a critical alert on 21 October 2026 and last reviewed it on 22 October. It says it is not aware of successful active exploitation within Australia, and recommends that organisations:

identify PHP within their environments
review the latest guidance from the PHP project
apply the available security updates and other appropriate mitigations
monitor PHP applications and related systems for suspicious activity.

Is it being exploited?

Outside Australia, reports differ and are changing quickly. At publication on 21 October, CISA said it had not observed exploitation. On the same day Cloudflare said it was seeing early attacks, and Amazon reported exploitation attempts against its honeypots, including one on 17 October, four days before disclosure. CERT-EU notes that proofs of concept are circulating. Plan on the basis that internet-facing PHP servers will be targeted.

How to check what you are running

Who updates PHP depends on how each site or application is hosted:

Shared or managed hosting, where most small business WordPress sites live: the host manages PHP. Ask it to confirm the fix is in place, and check which PHP version your site uses in the hosting control panel. If it is set to an older version such as 7.4 or 8.0, ask whether that version has been patched, or test and move the site to a supported version.
Your own server or VM: you or your IT provider update it.
Containers: rebuild images on a patched base image and redeploy. Running containers do not update themselves.
Packaged software and appliances that bundle PHP: check the vendor’s advisory. CISA specifically calls out PHP bundled inside other software.

On a server you manage:

php -v shows the command-line version, but the web server can run a different binary. Check the FPM version too (php-fpm -v, or a versioned name such as php-fpm8.3), or use a temporary phpinfo() page that you delete straight afterwards.
Distribution packages are often patched without changing the upstream version number, so a package can report an older version and still include the fix. Check your distribution’s security notice for the two CVE IDs rather than relying on the number alone. PHP says Linux distributions and long-term support vendors received the patches in advance.

Patch in this order

Internet-facing systems first: public websites, customer portals and APIs.
Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution’s patched package.
Restart every PHP worker: PHP-FPM pools, Apache and LiteSpeed. Updated files on disk do not protect processes still running the old code.
Confirm the running version, not just the installed package.
Then internal, staging and test systems, which are the ones most often forgotten.

For organisations working towards the Essential Eight, the patch applications strategy expects patches for internet-facing services to be applied within 48 hours when a vulnerability is assessed as critical by the vendor or a working exploit exists. php2shell meets that test.

If you cannot patch today

The PHP project is clear that only an update is a complete fix. These measures from its advisory reduce exposure to specific attack paths, but they do not make an installation safe:

For CVE-2026-109618: set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration. Set a low post_max_size (8M if the site takes no uploads, 32M if it does) and keep upload_max_filesize below it. Use a container or cgroup memory limit as the availability boundary, not RLIMIT_AS or RLIMIT_DATA.
For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini or the FPM pool, not with ini_set() or .user.ini, then restart every worker. On PHP 8.5, also set fatal_error_backtraces=0.
Put a web application firewall in front. Cloudflare has deployed WAF rules for the known exploit vectors on all plans, including Free. They only protect traffic that passes through Cloudflare, so make sure the origin server cannot be reached directly. Our Cloudflare guide covers the baseline, and our Cloudflare services cover the setup.
Take unpatchable systems offline. CISA’s advice for systems that cannot be updated, and for PHP 8.1 or earlier, is to take them offline until they are patched or upgraded.

After patching, check for signs of compromise

Exploitation attempts started before the fix was public, so patching does not undo an earlier compromise. On each internet-facing PHP system, look for:

PHP worker processes starting shells or downloading tools, the pattern CISA highlights.
New or changed PHP files in upload and web directories, especially since mid-October.
New administrator accounts in the CMS, and unexpected scheduled tasks or cron jobs.
Outbound connections from the web server to unfamiliar addresses.

If you find any of these, treat it as an incident: isolate the server, keep the logs, and rotate the credentials it held, such as database passwords and API keys. Rebuild from a known-good state rather than cleaning in place, which is where backups that survive an attacker matter. Report it to ASD’s ACSC through ReportCyber or on 1300 CYBER1 (1300 292 371), and check whether the Notifiable Data Breaches scheme applies if personal information may have been accessed.

Common questions

Has php2shell been exploited in Australia?

ASD’s ACSC says it is not aware of successful active exploitation within Australia. Exploitation attempts have been reported overseas, so patch internet-facing systems without waiting.

Does updating WordPress fix php2shell?

No. The vulnerabilities are in the PHP runtime, not in WordPress or its plugins. The server’s PHP has to be updated to 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a patched distribution package.

My site is on shared hosting. Do I need to do anything?

Usually the host updates PHP for you, but confirm it. Ask the host whether the fix is in place, and check that your site is not set to an old PHP version the host may not have patched.

What about PHP 7.4, 8.0 or 8.1?

There is no official PHP release for them. Use a patched package from your distribution or long-term support vendor, build from the PHP security team’s source backports, or upgrade to a supported version. If none of those can happen quickly, take the system offline.

What to do this week

List every system that runs PHP: hosted websites, servers, containers and packaged software.
Patch internet-facing systems first, restart every worker and confirm the running version.
Apply the interim measures, or take offline anything that cannot be patched yet.
Check patched systems for signs of compromise.
Plan upgrades off PHP 8.2 and older. PHP 8.2 support ends on 31 December 2026.

If you would like a hand finding and patching PHP across your websites and servers, or putting Cloudflare in front of them, get in touch. MSPs and IT providers who need extra hands across client environments can work with us as a partner.