PHP2Shell: Australia felt it.

Two flaws in the runtime, not a plugin

On 21 October 2026, PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The releases fix CVE-2026-109618 and CVE-2026-109619, two memory-safety flaws rated 9.2 under CVSS v4.0. Both can allow unauthenticated remote code execution. Researchers also demonstrated a way to read live PHP worker memory, including passwords, tokens and API keys belonging to other requests.

The details matter because this is not a WordPress plugin, a Drupal module or a bad theme. The bugs sit in PHP's own memory management and error handling. One is reached when a request runs out of memory at the wrong moment and cleanup treats partially initialised data as valid. The other leaves request-owned state pointing at freed memory; a later request on the same worker can reuse it. Every PHP installation serving web requests is in scope, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates the risk highest for mod_php, where an unauthenticated request can trigger the bug before application code runs.

The affected range is broad. Cloudflare says the vulnerabilities affect all web servers running PHP 5.4 or later. PHP 8.1 and older no longer receive project updates; some distributions and long-term support vendors have backported fixes. Updating application code alone does nothing. The runtime is the thing that has to change.

Why Australia noticed

The ABC reported outages at cyber.gov.au and other Australian government websites. A spokesperson for Home Affairs Minister Tony Burke said several Australian websites, including government sites, had been disrupted, and that some were temporarily unavailable while agencies mitigated the risk. The Australian Signals Directorate's Australian Cyber Security Centre published its own alert and told organisations to inventory PHP, apply vendor updates and watch for suspicious activity.

That is disruption, not proof of compromise. The ACSC said it was not aware of successful active exploitation within Australia at the time of its alert. Cloudflare, which sees traffic across a much larger estate, said it had observed attack traffic targeting its customers and watched attackers mutate payloads to evade its rules. Those are global exploitation attempts. They are not the same as a confirmed Australian breach.

NSW made the distinction explicitly. On 22 October, the NSW Government said some NSW Government websites had been taken down temporarily as a precaution while patches were applied. Cyber Security NSW was working with agencies, and no NSW Government agency had reported an information breach to it at that point. The sites went offline to reduce risk, not because someone had demonstrated they were already compromised.

The same pattern appeared overseas. The Netherlands, Finland and France took government services offline as a precaution. Wikipedia worked through the fix. A Danish municipal IT provider shut several services, including a national school communication platform. Those examples are useful context, but the Australian story is not a copy of them. It is about a public sector with a particularly large shared publishing footprint.

The Drupal footprint is real. It is not a breach count.

Australia's government web estate has a large shared Drupal footprint. The Australian Government Architecture describes GovCMS as a whole-of-government content management and hosting service built on Drupal, with more than 300 government websites for more than 100 government agencies. Victoria's Single Digital Presence says more than 60 websites use the platform, with more than 120 sections on vic.gov.au across all 10 departments. Its features page describes SDP as established on Drupal in 2016. nsw.gov.au says its platform runs Drupal 10 and will move to Drupal 11 in 2026.

Those numbers describe platform footprint. They do not say that 300 sites were vulnerable, that every agency was affected, or that anyone breached GovCMS. A Drupal site with a patched PHP runtime and current Drupal core is a different proposition from an unpatched one. The useful question is not "how many sites run Drupal?" It is "which services still run an affected PHP version, who owns them, and how quickly can they be updated and checked?"

Running Drupal is not the same as running a vulnerable PHP runtime. Running a vulnerable runtime is not the same as being exploited. And an outage is not a breach. Keeping those categories separate is basic incident hygiene. It also makes the response more useful: patch the runtime, update the application, check the logs, and only then draw conclusions about impact.

Cloudflare moved early. The WAF still is not the fix

Cloudflare says it had been developing and deploying WAF protections since early October, and the rules were live about nine hours before public disclosure. From 21 October at 03:02 UTC, customers on free and paid WAF plans were protected by default. The rules were not just request signatures. Cloudflare introduced full transaction detection, combining request and response signals in the same HTTP transaction, and used it to block responses that looked like successful exploitation. The company says it kept updating the rules as attackers changed payloads.

That is a serious piece of incident engineering. It bought time for organisations that could not patch within hours. It also shows why managed edge protection belongs in the plan: somebody else was watching the attack patterns while site owners were still working out which systems ran PHP.

It is still a layer, not a cure. A WAF can miss a variant, can be misconfigured, and does nothing for traffic that does not pass through it. The vulnerable code remains on the origin until the runtime is updated. Cloudflare's own advice is to keep the protections on and patch PHP as soon as possible. That order matters: protect, patch, then verify. Not protect instead of patch.

WAF helps. Patching is essential. The two actions belong together, but they are not interchangeable.

The engineering lesson is not "never use PHP"

PHP runs a large share of the web, including WordPress, Drupal, Joomla and MediaWiki. It is not going away, and it is not inherently unsafe. The failure mode here is familiar: a critical dependency sits under many services, the fix is in the runtime rather than the application, and the estate is large enough that inventory and change control become the hard part.

Good engineering is mostly invisible until a week like this. The organisations that coped best probably had a current inventory of what ran where, an owner for each service, a tested path from vendor patch to production, logs they could actually search, and a rehearsed way to take a service offline without losing data. They could answer "which PHP versions do we run?" without starting a spreadsheet from scratch. They could patch a shared runtime without waiting for ten application teams to agree.

That is not heroics. It is preparation. The same preparation pays off for a failed deploy, a compromised credential, a bad plugin update or a storage outage. It also changes the economics of incidents: less time spent discovering the estate, more time spent fixing the actual problem.

Managed protection is part of that preparation. So is observability. So is the decision to remove a runtime you do not need. That last one is an architecture choice, not a security silver bullet.

Where Workers and App Composer fit

Some applications do not need a traditional PHP stack. A small content site, an internal tool, a form, a catalogue or a focused public app can often run as an Astro application on Cloudflare Workers, with EmDash for editing and D1 or R2 for data and media. That removes PHP from the request path for that workload. It does not remove the need to patch Workers dependencies, manage access, back up data or test recovery. It changes the surface area, not the responsibility.

App Composer's supported route is deliberately concrete. Get Ready checks the environment, source and Cloudflare target before an idea. Init turns the app's content, fields and appearance into a portable specification. Creator stacks and the connected apps show how independent pieces can share data without becoming one monolith. The agent builds, previews, deploys and verifies the result. Each app keeps its own source and configuration.

That route suits a new application or a deliberate rebuild. It is not a one-click Drupal or GovCMS migration, and we should not pretend otherwise. A government platform carries content models, permissions, accessibility obligations, integrations, statutory records and years of editorial behaviour. Moving one is a project with its own discovery and acceptance. WordPress migration is further along, but it is still evaluated case by case: content, media, URLs, themes, forms, plugin behaviour, roles and transactions all need checking. The platform guide explains the current boundaries.

For a suitable workload, the benefit is straightforward: fewer self-managed moving parts, a smaller runtime surface, managed edge protection and a release path that can be tested. For an unsuitable one, the honest answer is to keep the current platform, patch it properly and improve the operations around it. Architecture should follow the work, not the campaign.

What to do now

1. Inventory PHP. Include containers, appliances, vendor products and shared hosting, not just the sites you remember. Record versions and owners.
2. Patch the runtime. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor backport. Restart workers so old state cannot survive. Updating a CMS or plugin is not a substitute.
3. Keep the WAF on. Treat managed rules as time and defence in depth. Check that the rules are actually deployed for the zones that need them.
4. Look for evidence, not headlines. Review PHP and WAF logs for exploitation attempts, unusual multipart requests, memory-limit errors and worker churn. Preserve logs before they rotate.
5. Verify the application. Check logins, forms, uploads and published content after patching. A 200 response from the home page is not a full check.
6. Fix the next incident before it happens. Name an owner, test a restore, document the rollback and rehearse taking a service offline. That work is less visible than a WAF rule and just as important.