On the evening of Wednesday 21 October, Australian government websites started disappearing. The Australian Signals Directorate posted at 9pm that it was aware of an outage affecting government sites, including its own cyber.gov.au. By the next morning the Australian Bureau of Statistics and Jobs and Skills Australia were briefly offline, and the ATO, the Health Department and ACMA appeared to be affected too. NSW took some of its sites down as a precaution. GovCMS blocked direct access to its servers and kept cached pages up, and the hosting company VentraIP restricted some file uploads on customer sites.
None of them reported a breach. The Science Minister said plainly that this was not one. They were getting ahead of a bug that, a few hours later at 1am Sydney time, the PHP project patched in an emergency release. Security researchers named it PHP2Shell.
If your business runs a WordPress site, a WooCommerce store, a Laravel app or anything else on PHP, this one is about you. This post covers what happened, why it is unusual, and what we think every founder and small business owner should check this week.
What Happened
PHP is the language behind a large share of the web. W3Techs puts it at 69% of websites whose server-side language it can identify, and it runs WordPress, Drupal, Joomla and Laravel.
On 21 October the PHP project shipped versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10 for severity. In plain terms:
- They are in PHP itself, not in an application. A website can have perfectly written code and still be exposed, because the flaws sit in how PHP handles a request before that code runs.
- No login is needed. An attacker sends crafted web requests and can end up running their own commands on the server. Researchers demonstrated this against WordPress, Drupal and Joomla.
- The entry point is on by default. One path abuses PHP's upload progress feature, which has shipped switched on since PHP 5.4. Akamai's analysis notes that any page accepting a file upload is reachable, even if the application ignores the upload.
- It can leak secrets. Researchers also showed the bugs can expose memory from other requests, which can include passwords, session tokens and API keys.
The PHP project says every installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with mod_php the most urgent.
An AI Found It, Twice
The part of this story that will matter long after the patch is how the bugs were found.
Two security firms found them independently, both with AI. Calif found the first flaw on 1 August as part of OpenAI's Patch the Planet program and reported it to PHP on 11 August. Wiz found its own on 19 August using OpenAI's GPT-5.6 Sol, Google's Gemini 4 Argon and its in-house Wiz Atlas tool, and confirmed working attacks against Drupal and WordPress within two days. OpenAI calls the time between AI finding a flaw and attackers finding it the Defender's Window.
That window was short. Details leaked a day before the planned release, a video of an exploit chain circulated overnight, and public proof-of-concept code was on GitHub within hours. Amazon says it logged an exploitation attempt four days before disclosure.
Wiz put the uncomfortable part plainly: bugs that used to be too hard to exploit to bother with are now worth an attacker's time, because AI has made building the exploit cheap. This is the same lesson as the agent incidents we wrote about in September, from the other side. The tools that help us build faster also help someone find the hole in what was built ten years ago.
The Version Nobody Can Patch
Here is the number that should worry small businesses more than the severity score.
Qualys looked across its customers' systems and found 71% of PHP installations on versions between 5.4 and 8.1. Those branches no longer get updates from the PHP project. There are minimal source backports for 7.4, 8.0 and 8.1, but nothing a typical hosting control panel will install for you. PHP 8.2 itself reaches end of life on 31 December.
In practice that describes a lot of the businesses who come to us. The marketing site built five years ago on shared hosting. The WooCommerce store that "just works" so nobody touches it. The internal tool a contractor wrote in Laravel and left behind. None of them are on anyone's maintenance schedule, which is exactly why they are still on PHP 7.4.
The good news so far: the Australian Cyber Security Centre's critical alert says it is not aware of successful exploitation in Australia, and Wiz said on 27 October it had not seen a successful end-to-end attack in its own data. A quiet first fortnight is not a reason to wait. A third, rarer upload progress issue, CVE-2026-115560, was disclosed on 23 October and is still waiting for its fix in the next regular release.
What to Check This Week
You do not need to be technical to get this done. You need answers to five questions, from whoever looks after your site.
- Do we run PHP anywhere? Not just the main website. Landing pages, a booking plugin, an old customer portal, a staging copy someone forgot. If you do not know, that is the first finding.
- Which version, exactly? It needs to be 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later on a supported branch, or a distribution build your host confirms includes the fix.
- Who applies the patch, and by when? On managed WordPress hosting this is often done for you. On shared hosting or your own server it usually is not. Get a name and a date from your host or developer.
- If it cannot be patched today, what is the stopgap? The PHP project's interim measures include switching off
session.upload_progress.enabledin the server configuration, not in application code, and restarting every PHP worker. It is explicit that these reduce exposure but do not make a site safe. For unsupported versions, the real answer is an upgrade, and until then restricting access or taking the site offline, as the government did. - Has anything already happened? Ask for a look at web and server logs from mid October onward for odd upload requests, crashed PHP workers or unexpected commands. If anything turns up, rotate the passwords and API keys that server could see.
Why We Build on a Different Stack
We do not build or maintain PHP. Every product we ship runs on TypeScript end to end: Astro and React for the front end, Node.js for the backend, deployed to Cloudflare Workers and AWS Lambda. This website runs the same way.
That choice is partly about exactly this kind of week. On Workers and Lambda there is no long-lived server sitting in a cupboard with an old runtime on it. The platform runs and updates the runtime, each request gets a fresh, isolated environment, and nothing about your site depends on whether someone remembered to restart the PHP workers. Static pages built with Astro have no server code to attack at all. Where a page does need a server, it is a small, typed function rather than a whole application server listening for uploads.
It does not make anything immune. Node.js has its own security releases, npm packages have their own supply-chain risks, and we treat both seriously. The difference is that the moving parts are fewer, they are on supported versions by default, and our CI/CD pipeline rebuilds and redeploys every project, so an update lands in minutes rather than becoming a project of its own.
Very few clients arrive with a blank page, though. That is why the reverse brief in a Flight Plan starts with what already exists, and why from this month it includes a short inventory of every system the business runs, with its language and version. For a business still on an old WordPress or Laravel build, PHP2Shell is the kind of event that turns "we should replace that site eventually" into a phase on the roadmap with a date next to it.
Ready to Move Off the Old Stack?
At Dev Force One, we rebuild ageing PHP sites and apps on a modern, serverless TypeScript stack, so there is no runtime for you to patch at 1am.
What you get:
- A modern stack: Astro and React on the front end, Node.js and TypeScript behind it, on Cloudflare Workers and AWS Lambda
- A planned migration: your content, data and integrations mapped in the Flight Plan, moved in phases, with the old site running until the new one is ready
- Updates without the drama: managed platforms and automated deploys in Cruise & Maintenance, so security releases ship in minutes
Still running WordPress or another PHP site you would rather not worry about? Book a Pre-flight call and we will map what moving it would take.