azureblog.co.uk
← cd ~/posts

The PHP flaw that took websites offline worldwide: what AI found, and what to do in Azure today

Two critical PHP flaws, found with the help of AI, sent organisations around the world scrambling to take websites offline today. PHP has released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix them. Here's what happened, and how to find every PHP app you run in Azure and get the fix as quickly as possible.

AzureNEW6 min read✓ checked 21 Oct 2026Azure · Security · What's new
On this page
  1. Websites went dark around the world
  2. How AI found it
  3. The fixed versions
  4. Find every PHP app you run
  5. Check the version an app is actually running
  6. Get the fix sooner with the Latest channel
  7. Custom containers and your own servers
  8. Signs to watch for
  9. Today's checklist
  10. Sources

The PHP team has released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 (Critical) on CVSS v4.0, and the PHP team says they can allow unauthenticated remote code execution. The release went out today, Wednesday 21 October 2026, from 14:00 UTC.

The PHP team's advice is short. There are no complete mitigations, so updating is the only safe choice.

Websites went dark around the world

The PHP team gave a day's warning on 20 October, and many organisations didn't wait for the patch. According to Reuters, the Dutch National Cyber Security Centre took its own website offline as a precaution, and the Port of Rotterdam, the government portal Overheid.nl, the KNVB, the country's five largest political parties and several hospitals followed. In Finland, the state IT provider Valtori took government public network services offline. France's Interior Ministry put all of its websites into maintenance mode. Denmark's municipal IT company Kombit shut several services, including the national school communication platform. Wikipedia's operator took some systems down until they were patched, and the Internet Archive went briefly offline.

Universities did the same. The University of Freiburg, for example, took its central websites, WordPress sites, intranet, learning platform and student webmail offline as a precaution.

That's in line with the UK NCSC's advice. It says to find every PHP installation, starting with anything internet-facing, and update. If you can't update or mitigate quickly, it says to consider taking the system offline until you can, and to check for signs of compromise before bringing it back.

How AI found it

AI did much of the digging here. Wiz Research says it found the flaws using its own AI vulnerability research tool, Wiz Atlas, together with Google's Gemini 4 Argon and OpenAI's GPT-5.6 Sol. It credits Gemini 4 Argon with an "invaluable contribution" to finding the vulnerability. The models then helped adapt working exploits to different PHP versions, configurations and memory layouts, with testing and debugging tools feeding failures back so they could try again. Separately, the security firm Calif told Reuters that a large language model helped it find the flaws on 1 August.

The bugs had been in PHP for more than a decade. Wiz says nearly every PHP version back to 5.4 is affected. Both flaws turn on what happens when PHP hits a fatal error, especially running out of memory, in the middle of handling a request. State left behind can be reused by a later request on the same worker. Wiz showed unauthenticated remote code execution against WordPress, Drupal and Joomla, and memory disclosure that works whatever the application.

The timeline shows how long a coordinated fix takes. Wiz found the first flaw on 19 August, reported it to the PHP team on 24 August, and the fix went public today. The worry now runs the other way. Experts quoted by Reuters warn that the same AI tools can work backwards from the public fix to a working exploit with little effort, so the gap between disclosure and attacks may be very short.

The fixed versions

BranchUpdate to
PHP 8.58.5.12
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35
PHP 8.1 and olderNo release, and Wiz says they're affected too. These branches are end of life, so move to a supported branch.

Find every PHP app you run

PHP is only supported on App Service on Linux. PHP on Windows App Service reached end of support in November 2022, so any Windows app still running PHP is yours to patch.

This query lists every Linux web app and deployment slot running a built-in PHP stack, across every subscription you can see. Run it in Resource Graph Explorer in the portal:

kql6 lines
resources
| where type =~ "microsoft.web/sites" or type =~ "microsoft.web/sites/slots"
| mv-expand p = properties.siteProperties.properties
| where tostring(p.name) =~ "LinuxFxVersion" and tostring(p.value) startswith "PHP|"
| project name, resourceGroup, subscriptionId, stack = tostring(p.value)
| order by stack asc

It won't find PHP running in a custom container, on a VM or in AKS, so check those separately.

Check the version an app is actually running

The stack setting tells you the branch, such as PHP|8.4, not the patch level. To see the exact version, open WebSSH at https://<app-name>.scm.azurewebsites.net/webssh/host and run:

text1 line
php --version

If it shows a version lower than the one in the table above, the app doesn't have the fix yet.

Get the fix sooner with the Latest channel

Microsoft is updating the built-in PHP images for App Service on Linux. How soon an app gets them depends on its Platform Release Channel:

  • Latest gets the fix first.
  • Standard, the default, gets it through an accelerated rollout.
  • Extended gets it last. Microsoft says it usually stays one release behind Standard.

For anything internet-facing, move to Latest for now. Open the app, go to Stack settings, choose Latest under Platform Release Channel and select Save. At the very least, move apps off Extended.

If an app is still on PHP 8.1 or older, there's no fixed image to wait for. Move it to a supported branch, testing in a staging slot first:

shell3 lines
az webapp list-runtimes --os linux | grep PHP

az webapp config set --resource-group <resource-group> --name <app-name> --slot staging --linux-fx-version "PHP|8.4"

When the staging slot looks right, swap it into production.

Custom containers and your own servers

App Service doesn't patch PHP you bring yourself. If you run PHP in a custom container, rebuild the image on a fixed PHP version and redeploy. Do the same for container apps and AKS. On VMs and on-premises servers, update PHP from your distribution's or the PHP team's packages, then restart PHP-FPM or the web server, because running processes keep the old code until they restart.

Signs to watch for

Until everything is patched, Wiz suggests looking out for unusual multipart requests followed by memory-limit errors, repeated HTTP 500 responses, unusually large or malformed PHPSESSID cookies, and PHP workers restarting for no obvious reason. In App Service, the application logs and the Diagnose and solve problems blade are the places to look.

Today's checklist

  1. Run the Resource Graph query and list every PHP app, plus any custom containers, VMs and AKS workloads running PHP.
  2. Move internet-facing apps on built-in images to the Latest channel, and everything else off Extended.
  3. Rebuild custom containers and update servers you manage yourself.
  4. Plan the move to a supported branch for anything on PHP 8.1 or older.
  5. Anything you can't patch or protect today, consider taking offline, as the NCSC suggests.
  6. Check php --version again once the update has rolled out.

Sources