PHP's critical patch exposed NZ's legacy web debt: what to fix

What happened

On 21 October 2026 (UTC), the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The releases fix two remote code execution flaws, CVE-2026-109618 and CVE-2026-109619. New Zealand's National Cyber Security Centre (NCSC) issued an alert warning that the flaws could allow unauthenticated code execution on affected servers. The alert also said the NCSC was aware of reports of active exploitation. The NCSC's news update put the patch's NZ arrival at 3am NZDT on 22 October and told organisations to patch immediately.

In the past week, attention has moved from the patch to how many New Zealand systems can't take it. On 6 November, IT Brief reported an analysis by hosting company Webscape of public Shodan data. Webscape counted 1,158 New Zealand servers that visibly ran PHP. Of those, 991 disclosed a version number, and 560 of the 991 ran versions that no longer receive security updates. PHP 7.4 and PHP 5.6 were the most common unsupported versions, and nearly 250 servers ran PHP 5 or older. Webscape's count leaves out sites behind content delivery networks and sites that hide version details, so the real number is probably higher. A version string alone also can't prove a server is vulnerable, because some Linux distributions backport fixes into older version numbers.

On 9 November, the NCSC's Dr Emma Bickerstaffe repeated the warning to businesses. She said firms shouldn't assume an update ends the job and should check for signs of unusual activity. The same report said it was still too early to judge the full impact on New Zealand organisations.

Why the old versions are the hard part

PHP.net publishes no fixed release for PHP 8.1 or older, according to security firm Sansec. PHP's security team released source patches for 7.4, 8.0 and 8.1, and several Linux distributions and paid extended-support vendors have backported the fix. The NCSC's guidance says end-of-life versions stay vulnerable unless the owner compiles custom source patches or gets backports from an enterprise operating system vendor. Sansec says the vulnerable code goes back to PHP 5.4.0 from 2012. A business running PHP 5.6 on a basic hosting plan has no realistic route to a fix short of upgrading.

Sansec has since lowered its estimate of the risk. The firm now considers mass exploitation less likely because a successful attack needs particular server conditions and knowledge of the target. Even so, Sansec still advises updating. The lower risk from these two bugs doesn't help a PHP 5.6 server much, because that server will also miss the fix for whatever PHP flaw comes next.

The calendar adds pressure. PHP's supported versions page shows security support for PHP 8.2 ending on 31 December 2026. A site that moved to 8.2.35 last month has about seven weeks before it joins the unsupported group Webscape counted. PHP 8.4 has security support until 31 December 2028, and PHP 8.5 until 31 December 2029.

Why a patching story belongs in digital transformation

The NZ Herald cites an estimate that PHP runs about 70% of the world's websites. In the same article, consultant Adam Holt reported scanning .nz sites with AI agents on 22 October. He found that 86% of sites showing a PHP version still hadn't patched by 4pm that day, and that about a third ran versions with no official fix. Holt's figures come from his own scanning, not from an official count. Even so, Holt and Webscape reached broadly the same conclusion using different methods.

We see the same pattern in many organisations. An agency built a website, booking system or customer portal several years ago, and the site has run well enough since. Nobody internally treats the PHP runtime underneath as an asset with an expiry date. The hosting plan renews automatically, and the original developer may have moved on. Upgrading from PHP 5.6 or 7.4 to 8.x usually involves code changes, plugin replacements and testing, so the upgrade gets deferred until a vulnerability like this one forces the issue. For many owners, the upgrade cost now competes with the cost of rebuilding the site on a current platform. That rebuild decision is a transformation decision with budget and timing attached, which is different from a routine patch.

The same gap affects equipment people don't think of as websites. The NCSC's updated alert notes that some firewalls, edge devices and other embedded platforms run PHP and may need separate assessment under each vendor's guidance. An organisation's web server can be fully patched while a management interface on a network appliance stays exposed.

What NZ businesses should do now

• List every system that might run PHP. Include public websites, ecommerce stores, customer and supplier portals, intranets, and the admin interfaces on firewalls and network appliances. Ask each supplier whether their product uses PHP, as the NCSC recommends.
• Get the PHP version and patch status in writing. Ask your developer or host for the exact version, whether the October fix is applied, and whether they checked for compromise before patching. The NCSC suggests the same questions.
• Decide what to do with anything on PHP 8.1 or older. The realistic options are upgrading, moving to a supported distribution or paid extended-support service with backported fixes, or taking the service offline. The NCSC has said organisations that can't patch should consider disabling public-facing web services.
• Book the PHP 8.2 upgrade before 31 December. Moving to 8.4 or 8.5 gives two to three years of security support. Leave time for plugin and code testing before the holiday shutdown.
• Check for signs of compromise. Look for unexpected website changes, new administrator accounts, outages and unusual login activity, as listed in the NCSC's advice. A patch doesn't remove an attacker who got in before the fix was applied.
• Record runtimes and their end-of-support dates in your asset register. Link those dates to your change process so the next upgrade is scheduled before support ends. Our ITIL 4 service management work covers this kind of lifecycle tracking.

For systems that are too old to upgrade cleanly, the choice between fixing and replacing is worth making deliberately, with costs and a deadline. We cover that decision in our digital transformation services. Publicly available information doesn't yet show how many New Zealand sites were compromised through these flaws. The number of NZ servers that can't receive the October fix at all is already known, and that number grows on 1 January 2027 when PHP 8.2 support ends.