PHP2Shell: the WordPress patch won't save you. Here's how to check your PHP version tonight.

If your website runs on WordPress, Drupal, Joomla, Magento, Laravel or any custom PHP code, this week's emergency isn't in a plugin. It's in PHP itself, the engine underneath. Clicking "Update" in your WordPress dashboard won't fix it.

On 21 October 2026, Australia's ASD's ACSC issued a critical alert about two vulnerabilities in PHP, and business.gov.au followed on 23 October with advice for small businesses. The flaws are tracked as CVE-2026-109618 and CVE-2026-109619 and are nicknamed php2shell (CISA).

Quick note so nobody mixes them up: this is a different issue from the July WordPress flaw we covered in our wp2shell post. That one was in WordPress. This one is in PHP, so it affects far more than WordPress sites.

What's going on, in plain terms

• It's serious. The PHP security team rates both flaws CVSS 9.2. Some early reports said 10.0, which the PHP Foundation says was wrong (Tenable).
• No login needed. An attacker could run code on your server without signing in. CVE-2026-109619 can also leak memory contents (CISA).
• It's in the engine, not your site. Wiz Research says even a basic "Hello World" PHP page on a vulnerable runtime can be exposed. Vercel's bulletin makes the same point: updating your CMS, theme or plugins does not patch PHP.
• It's already being used. Amazon Threat Intelligence saw an exploitation attempt on 17 October, four days before public disclosure, and later said it was broadly exploited (Tenable). CISA added both flaws to its Known Exploited Vulnerabilities list on 26 October (CISA).
• It's widespread. W3Techs puts PHP on about 69.3% of websites where the server-side language is known (Tenable, citing W3Techs). Public researchers roughly estimate 1.3 million to 1.9 million internet-facing PHP hosts (same source). Those are rough outside estimates, not our numbers.

Am I affected?

Probably, if anything you own runs PHP and serves web pages. That includes setups using Apache mod_php (which PHP says is the highest risk), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed (CISA). The affected code goes back to PHP 5.4, so nearly every PHP version from the last decade is hit by at least one of the two flaws until it's patched (Wiz).

Fixed versions (CISA, Cyber Centre Canada):

• PHP 8.5: update to 8.5.12 or later
• PHP 8.4: update to 8.4.27 or later
• PHP 8.3: update to 8.3.36 or later
• PHP 8.2: update to 8.2.35 or later
• PHP 8.1 and older: end of life, with no official fixed releases. PHP has published minimal source backports for 7.4 to 8.1, and some Linux distributions or long-term support vendors may ship packages. Ask your vendor, or move to a supported branch (Tenable).

How to check your version:

• Shared or managed hosting (cPanel, Plesk and similar): look for "PHP version" or "Select PHP version" in your hosting panel. Many panels also show it on the dashboard.
• Your own server or VPS: run php -v on the command line. Keep in mind the command-line version can differ from what the web server is actually using, so ask your developer to confirm the version the site runs.
• Not sure? Email your host or developer and ask: "What exact PHP version is each of our sites running, and when were the PHP workers last restarted?"

What "patched" actually means

Patched means two things:

1. The PHP version is one of the fixed versions above, and
2. Every PHP worker has been restarted or replaced since the update went in (PHP-FPM, Apache and so on).

Installing the update alone isn't enough. Until the workers restart, the old code keeps running in memory (Tenable, citing Google Cloud / Mandiant guidance). If your host says "we've updated", ask whether they've restarted too.

The 30-minute owner checklist

Copy this into a note and work through it tonight:

1. List every web address you own. That means the main site, online shop, client portal, booking page, and any staging., dev. or old. subdomains. Check your domain registrar and DNS for ones you've forgotten.
2. Write down who hosts each one and who has the login: you, a developer, an agency or the hosting company.
3. Find the PHP version for each using the steps above.
4. Mark each one as fixed, needs update, or 8.1 or older (unsupported).
5. Ask whoever runs each site to confirm the update and the worker restart, in writing, with the date.
6. Check how updates happen. Does your host patch PHP automatically, or does someone have to do it by hand? Most WordPress auto-updates only cover WordPress, not PHP.
7. If you use Cloudflare, check whether each site is "Proxied" (orange cloud) or "DNS only" (grey cloud). Cloudflare's emergency rules only cover proxied traffic.
8. Switch off what you don't need. An old staging site nobody uses is easier to take offline than to patch.

The forgotten site is usually the real risk for small businesses. The main website gets looked after, but the 2022 staging copy, the old campaign landing page and the portal a former developer set up often keep running on old PHP with nobody watching them.

Can't patch tonight?

• CISA's advice is blunt: if you can't update, or you're stuck on PHP 8.1 or older, take PHP-based systems offline until they're patched (CISA). business.gov.au also says to consider going offline until patched.
• Web application firewalls help, but they aren't a fix. Cloudflare has rolled out rules for known attack paths on all plans, including free, but they only cover proxied traffic and are a stopgap (Tenable).
• Partial config changes exist. PHP lists a few settings that close off some paths, but they're incomplete and still need a worker restart (same source). Leave them to your developer or host, and treat them as a bridge to patching, not a substitute.
• Ask your host for an emergency PHP upgrade. Most managed hosts can switch you to a supported, patched version quickly.

After patching: what to watch for

Because the exploitation attempt was seen on 17 October, check activity from at least 17 October, not just from 21 October (Tenable). Ask your developer or host to look for:

• PHP worker processes starting shells or downloading tools (CISA)
• Unusual upload-style (multipart) requests followed by memory-limit errors or a run of HTTP 500 errors (Wiz)
• Unexpectedly large or malformed PHPSESSID cookies (same source)
• PHP workers restarting or crashing for no clear reason (same source)

Wiz notes that your application logs may show very little, because the problem sits below the app. Server and web-server logs matter more here. If you find anything odd, the ACSC can help on 1300 CYBER1 (1300 292 371) (business.gov.au).

Where OrionX can help

If you're not sure how many PHP sites you actually have, or who looks after them, that's exactly what we sort out with Adelaide and SA businesses. We can help you:

• list every WordPress and PHP site and host you own, including old staging copies
• confirm each one is on a fixed PHP version and the workers have been restarted
• work out what to check from 17 October onwards
• get interim protection in place with your host where a patch can't go in the same day

Book a free 20–30 minute chat. If it's a good fit, we'll follow up with one free demo tailored to your setup (one per business). No pressure, just a clear picture of where you stand.

Sources

• ASD's ACSC: Critical vulnerabilities in PHP (21 Oct 2026)
• business.gov.au: Critical vulnerabilities found in PHP (23 Oct 2026)
• CISA: Critical vulnerabilities in PHP require immediate patching
• Tenable: PHP2Shell FAQ
• Wiz Research: php2shell
• Canadian Centre for Cyber Security: AL26-026
• Vercel: PHP2Shell security bulletin
• BleepingComputer: PHP ships emergency patches for critical php2shell flaws