PHP2Shell: The Critical PHP Vulnerability Every Australian Website Owner Needs to Patch Now

On 21 October 2026, the PHP project shipped emergency fixes for two critical flaws in PHP itself. Nicknamed PHP2Shell, they let an attacker run their own code on your web server without logging in. If your website runs on WordPress, WooCommerce, Laravel, Drupal, Joomla or a custom PHP build, you are in scope until you confirm otherwise.
This isn’t a plugin problem you can fix with one click in your dashboard. The flaw sits in the engine under your site, so you have to patch it at the server level. Attackers have already moved: Cloudflare reported attempts climbing from tens of thousands within 45 minutes of disclosure to millions by the next morning.
Here’s what PHP2Shell is, how to check your site, and what to do this week.

What is PHP2Shell?

PHP2Shell is the name for two remote code execution (RCE) vulnerabilities in the PHP core: CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 out of 10 (CVSS v4.0, critical).

• CVE-2026-109618: When PHP runs out of memory mid-request, it can leave half-built internal data behind. An attacker can trigger this deliberately with a crafted request and turn the mess into code execution.
• CVE-2026-109619: A PHP worker can carry stale, already-freed memory from one request into the next. An attacker can abuse that leftover state to take control.

In plain terms: someone anywhere on the internet can send your server the right request and gain the same access your website has. That means your files, your database and your customers’ data.

Why this one is different

• It’s in PHP itself. Every PHP version from 5.4 through 8.5.11 is affected, regardless of which CMS or plugins you use.
• Attacks started before the patch. Amazon’s threat team logged an exploit attempt on 17 October, four days before public disclosure, after details leaked early.
• Public exploit code exists. Proof-of-concept tools are on GitHub, so low-skill attackers can run automated scans.
• Governments are sounding the alarm. The ACSC, the UK’s NCSC and CERT-EU have all told organisations to patch immediately or take PHP sites offline until they can.
• No complete workaround. The PHP team has been clear: updating PHP is the only real fix.

On 23 October, PHP also flagged a third, lower-risk issue (CVE-2026-115560) affecting only unusual session configurations. It’s not under attack and will be fixed in a routine release, but it’s another reason to stay on a supported, current PHP version.

Is your website affected?

If your site runs PHP and it’s older than the patched release for its branch, assume it’s vulnerable.
 

Still on PHP 8.1, 7.4 or older?

You won’t get a fix. You’ll need to upgrade to PHP 8.3 or 8.4 first, then apply the patch. We recommend skipping 8.2: it’s patched, but its security support ends on 31 December, so you’d be doing this again in two months.

Older themes and plugins can break on a newer PHP version. Always test the upgrade on a staging copy before touching your live site.

How to check your PHP version

• WordPress: Tools → Site Health → Info → Server. The PHP version is listed there.
• cPanel: Look for “Select PHP Version” or “MultiPHP Manager”.
• Cloudways, WP Engine, SiteGround and other managed hosts: Check the server or site settings panel, or your host’s status page.
• Linux packages (Ubuntu, Debian, RHEL): Distributions often backport fixes without changing the version number, so check your vendor’s advisory rather than relying on the number alone.
• Not sure? Ask your host or developer. They should be able to answer the same day

What to do now

1. Back up first. Take a full backup of files and database, stored off the server, so you can roll back if an upgrade breaks something.
2. Patch PHP. Move to a safe version from the table above. On managed hosting, your provider may have already done it, but get confirmation in writing that your specific server is patched.
3. Restart PHP. The fix only takes effect once PHP-FPM or your web server is restarted. Containers need to be rebuilt from a patched base image and redeployed.
4. Update everything that runs on PHP. WordPress core, plugins and themes, or your Laravel and Composer packages. This doesn’t fix PHP2Shell, but it closes the other doors attackers are trying at the same time.
5. Reduce exposure if you can’t patch today. Put a web application firewall (WAF) in front of the site (Cloudflare shipped PHP2Shell rules on 21 October), block public access to staging sites, admin tools and old microsites, and switch on uptime and security alerts. These buy time; they don’t fix the flaw.
6. Check for signs of compromise. Attacks began before patches existed, so a patched site may already be infected. Look for:
   • Admin accounts you didn’t create
   • Unfamiliar or recently modified PHP files, especially in uploads or plugin folders
   • Odd redirects, pop-ups or spam pages
   • Warnings in Google Search Console or the browser
   • Spikes in outgoing email or server load
7. Rotate credentials. If anything looks off, or you patched after 22 October, change hosting, database, SFTP and admin passwords, regenerate API keys, and turn on two-factor authentication.

Common mistakes to avoid

• “WordPress auto-updates will handle it.” They won’t. WordPress updates touch WordPress code, not the PHP engine running it.
• Assuming your host has patched. Many have, some haven’t, and some leave PHP versions to the customer. Confirm it for your server.
• Patching but not restarting. Old PHP workers keep running the vulnerable code until they’re restarted.
• Forgetting forgotten sites. Old landing pages, staging copies and microsites on the same server are an easy way in.
• Treating a firewall as the fix. A WAF lowers the risk. Only the patch removes it.
• Upgrading PHP without testing. Jumping from 7.4 to 8.4 on a live site with no backup can take you offline for days.

How Just WebOps can help

Already on a Just WebOps support plan? We’re on it. Our team is checking PHP versions, confirming patches with your host, and reviewing your site for signs of compromise. We’ll be in touch if anything needs your sign-off.

Hosted or managed elsewhere, or not sure where you stand? Our Australian and offshore teams cover the clock, so we can move fast. We’ll:

• Check which PHP version your site actually runs, including staging and old subdomains
• Patch PHP, or upgrade end-of-life versions on a staging copy first
• Update WordPress, WooCommerce, plugins and themes
• Scan for web shells, rogue admin users and modified files
• Tighten access with password rotation, 2FA and a WAF

We work on WordPress, WooCommerce, Laravel and custom PHP, across cPanel, Cloudways, WP Engine and most other hosts.

Get your site checked and we’ll come back to you the same business day, or call us on +61 7 3523 3848.

Not ready to hand it over? A Free Website Audit will tell you where your site stands, PHP version included.