What to do about PHP2Shell

A public reference on how New Zealand and Australian websites stand on the two serious PHP flaws (rated critical by the PHP project) disclosed and fixed on 21 October 2026. It compares a census of 277,875 unique .co.nz domains checked on 22 October 2026 (NZ time) with a census of .com.au domains given the same check, starting about 4½ hours after New Zealand’s finished. For New Zealand it also shows an hourly re-check of the sites that showed an exact PHP version. We corrected the census counts on 22 October; see Corrections. It does not name or list any individual site.

Both countries got the same check: one ordinary homepage request per domain, the same software reading the same headers, and the same rule for counting each domain once. The lists of names differ: the Australian list drew on more public sources (see Method), which may be part of why more Australian sites showed a version. The head-to-head figure is the share of sites showing an exact PHP version that were visibly patched when we checked them: 9.1% of 19,122 in New Zealand and 4.5% of 192,892 in Australia. Every figure is a percentage of a group we name next to it, because Australia has many more websites. Australia’s check started about 4½ hours after New Zealand’s finished, which gave its hosts more time to install the fix. The New Zealand hourly tracker and the Australian tracker are later, separate measurements, so we don’t set them against each other or against the censuses.

There are many more .com.au names than .co.nz names, so the Australian census took longer. We checked them politely, one request per site at a steady rate, in roughly alphabetical order. While it ran, the page showed interim figures that updated every hour. The census finished at 3:53 am NZDT on 23 October, and the Australian census figures on this site are now final.

No. It compares one thing: how many sites that announce their PHP version were visibly patched at the moment we checked. Most sites don’t announce a version, many hosts patch without changing the version number, and Australia was checked later. A higher share patched is good news for those sites, not a security rating for a country.

On 21 October 2026 the PHP project disclosed and fixed two serious flaws, rated critical by the PHP project (CVE-2026-109618 and CVE-2026-109619, nicknamed “PHP2Shell”). In some set-ups they can let someone take over a web server without a password. PHP runs most WordPress sites. New PHP releases with the fix came out on 21 October for supported versions only: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Hosting platforms such as cPanel, Plesk and CloudLinux, and Linux distributions, commonly ship backported fixes without changing the version number, including for older PHP. New Zealand’s National Cyber Security Centre says: “The NCSC is aware of reports of active exploitation.”

Each PHP version is supported for a fixed period, usually four years. After that, the PHP project stops publishing security releases for it, and the version is “end-of-life”. PHP 8.1 and older are past that point, so there is no new release from the PHP project. It can still be patched, though. Hosting platforms such as cPanel, Plesk and CloudLinux, and Linux distributions, commonly ship backported fixes without changing the version number, so a site on one of those versions may already be fixed. Ask your host. The long-term fix is still to move to a supported version (8.2 or newer).

Ask your web developer or hosting company which PHP version your site runs and whether the 21 October fix, or their backport of it, is installed. Some sites also show the version in a response header called X-Powered-By, which you can see in your browser’s developer tools (Network tab). If no version is shown, that does not mean the site is safe. The goal is PHP 8.2 or newer, kept up to date. Sites built on hosted services such as Squarespace, Wix or Shopify are maintained by those companies.

First ask your host whether the PHP2Shell fix, or their backport of it, is installed. Then ask them to move your site to PHP 8.2 or newer with the latest update installed. Before or alongside that, update your website software, theme and plugins, because older ones may not work on newer PHP. Take a backup first and check the site afterwards. If you don’t know who hosts your site, your web developer or domain provider can usually tell you.

No. “Not visibly patched” does not mean vulnerable. It means the server reports a PHP version number older than the 21 October fix. Two big caveats cut both ways. First, we only see sites that disclose their PHP version (19,122 in New Zealand, 192,892 in Australia), and most servers don’t; we can’t say how the hidden ones compare. Second, many sites that look unpatched may already be fixed: hosting platforms such as cPanel, Plesk and CloudLinux, and Linux distributions, commonly ship backported fixes without changing the version string, so a server reporting, say, 7.4.33 or 8.2.34 may be patched. Plesk (on Linux) and CloudLinux say they have released fixed builds of PHP 7.4, 8.0 and 8.1 that keep the old version number; the fixed versions table lists them (Plesk, CloudLinux). The check is passive, one ordinary homepage request per site with no scanning or probing, and it’s a point-in-time snapshot that updates as hosts apply fixes. Treat the patched share as “who we can see is patched”, not a vulnerability count. See Method and caveats for detail.

The data and analysis are by TheColab.ai. You’re welcome to cite the figures with credit.