PHP2Shell: What Australian Businesses Should Do Now About the Critical PHP Flaws

Summary

On 21 October 2026, PHP shipped emergency releases for PHP2Shell, two critical flaws in the PHP engine itself (CVE-2026-109618 and CVE-2026-109619, both CVSS 9.2). A single anonymous web request can run code on the server, before any of the website’s own code runs. A related path can leak server memory, including passwords, session tokens and API keys.

PHP runs most of the web, including WordPress, WooCommerce, Magento, Joomla and Drupal. Researchers confirmed full takeover of default WordPress, Magento, Joomla and Drupal installs, among others. Details leaked a day before the planned disclosure, and Cloudflare and watchTowr both reported attack traffic on 21 October.

If your business has a website, assume you’re affected until your host or IT provider confirms otherwise.

Are you affected?

Field	Detail
Affected	PHP serving web requests, from 5.4 onwards: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed
Fixed in	PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12
No official fix	PHP 8.1 and older (end of life)
Login needed	No

The fix is in PHP on the server. Updating WordPress, plugins or themes does not fix PHP2Shell. If a hosting company runs your site, they have to apply it.

What to do, in order

1. Update PHP today

Upgrade every internet-facing server to a fixed version, or install your Linux distribution’s patched package. Distributions and long-term support vendors received the fix before release, so their packages may carry a different version number. Check their advisory.

If you install PHP from the community Remi repository (common on RHEL-based servers), it had no fix on release day. Switch to your distribution’s packages or build from source.

2. If someone else hosts your site, ask them in writing

Send your host or web developer this:

Have you updated PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or applied your vendor’s patch for CVE-2026-109618 and CVE-2026-109619, on every server that hosts our sites? If not, when?

Ask about every site you own, including old campaign sites, staging copies and anything a former agency built.

3. Put a web application firewall in front

Many business websites already sit behind Cloudflare, and that’s good news here. Cloudflare built PHP2Shell protections ahead of disclosure and switched them on automatically from 21 October, about nine hours before the details went public. The rules check both the incoming request and the server’s reply, so they can stop an attack, or a memory leak, before it reaches the attacker.

• Free plan: you’re covered automatically. There’s nothing to turn on.
• Paid plans (Pro, Business, Enterprise): check that the Cloudflare Managed Ruleset is deployed in block mode.
• Check it’s actually in the path: protection only applies to traffic that goes through Cloudflare. Your site’s DNS records need to be proxied (the orange cloud), and your server shouldn’t accept web traffic sent straight to its own IP address.

Cloudflare reports the rules are already blocking real attack traffic, and that attackers are changing their payloads to get around them. Cloudflare is updating the rules as new variations appear. A firewall buys you time, but it doesn’t fix PHP, so keep it on while you patch, not instead of patching.

4. If you can’t patch today

These reduce risk, but none of them is complete:

• Take the site offline or serve a static page. The UK’s NCSC recommends considering this for systems that can’t be fixed straight away. WordPress and Magento maintenance modes don’t help, because PHP processes the request before the application checks the flag.
• Turn off upload progress tracking. Set session.upload_progress.enabled = Off. On PHP-FPM, set it in each pool’s config, not just the command-line php.ini, then reload. Sansec warns this alone isn’t enough.
• Block file-upload requests. Rejecting multipart/form-data requests on paths that don’t need uploads removes the main entry point, but it breaks forms and uploads that do. Test your checkout and contact forms afterwards.

5. Retire end-of-life PHP

Servers on PHP 8.1 or older won’t get an official fix. PHP has published minimal source backports for 7.4, 8.0 and 8.1, but treat these as a stopgap. Plan the upgrade now, and until then keep those servers off the public internet or behind a VPN.

6. Find the PHP you forgot about

Inventory web servers, intranets, hosting control panels such as cPanel and Plesk, and vendor appliances or Windows software that ships its own php-cgi.exe. The long tail of forgotten installs is where incidents will come from.

Check whether you were hit

Look for:

• PHP processes (php-fpm, php-cgi, httpd, apache2) starting sh, bash, cmd.exe, powershell.exe, curl, wget or certutil.exe
• New or changed PHP files in the web root, /tmp or /var/tmp
• New admin accounts, cron jobs or scheduled tasks
• Bursts of HTTP 500 errors or memory-limit errors after upload requests, and unusually large PHPSESSID cookies

If a site was online and unpatched after 20 October, consider rotating the secrets it holds: admin passwords, database credentials, API keys and payment gateway tokens. The memory leak can expose them without leaving obvious traces. If you find signs of compromise, isolate the server, preserve its logs and report it to ASD’s ACSC at cyber.gov.au. If personal information may have been accessed, the Notifiable Data Breaches scheme may apply.

How AI made this faster

The underlying bugs sat in PHP for more than a decade. Wiz Research, which reported them with Calif and OpenAI, says frontier AI models were critical to finding them and chaining them into a working exploit. In Wiz’s words, “a single researcher completed in a week what previously would have taken a world-class team months of work.” Wiz adds that the same models can quickly adapt an exploit to different PHP versions and server setups.

That cuts both ways. The defenders used AI to find and fix PHP2Shell, but attackers have the same tools for turning a leak or a patch into an attack. Here, Cloudflare saw attacks hours before the official fix shipped.

What this means for you: patching “in the next maintenance window” is no longer good enough for critical, internet-facing flaws. Know who patches your servers, how to reach them out of hours, and how quickly they commit to acting.

---

This summary draws on advisories and research from the PHP security team, Wiz, Sansec, Huntress, Cloudflare and watchTowr, published 20–22 October 2026. Details are still emerging, so check your vendor’s guidance. It contains no exploit code.