PHP fixed two flaws in its core on October 21 that let a single request run code on a web server. Wiz, which found them, says every PHP version of the last decade is affected.

If you look after other people's sites, today's question is not whether to patch. It is which servers, in what order, and what to tell each client, and the spreadsheet you usually answer it with may be wrong.

What happened

PHP released fixes for CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4.0, in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Help Net Security reported that branches 8.1 and older get no official release; the PHP security team published minimal source backports for 7.4, 8.0 and 8.1.

Wiz, which found the flaws, wrote: "Every PHP version released in the last decade is affected by at least one of these vulnerabilities," and "Exploitation does not depend on a flaw in the application's code." Help Net Security described the working exploit this way: a single unauthenticated request can trigger the attack before any application code runs, and setups using Apache's mod_php face the greatest danger.

Wiz also says AI did real work here: "Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit."

Cloudflare deployed firewall rules for the known exploit paths on all plans with its WAF, including Free, starting October 21. The UK's cyber security agency, the NCSC, advised that if you cannot apply the temporary mitigations, "you should consider taking the system offline until it can be fully mitigated."

Two labels. Whether attackers are already using the flaws is contested: some security firms report exploitation and others had not seen it, so we make no claim either way. And Wiz's "70% of the Internet" is its own framing; W3Techs puts PHP at 69.3% of websites whose server-side language it can identify.

What we propose, and the run

An agency's morning-after problem is not the patch itself. It is that the record of what each client runs lives in a spreadsheet, and a spreadsheet is only as current as the last person who touched it.

So we propose a morning-after triage. The A.I. reads the advisory and each row of the agency's sheet, judges the site and drafts the client's email. Then our code asks each server, through the host's panel, what PHP it actually runs, and decides. From the prototype's README, decision 1: "The version comes from the server, never from the sheet or the model."

Three more rules sit next to it:

  1. A firewall buys time; it never marks a site safe. A site behind Cloudflare on an unpatched version is still "update today".
  2. An end-of-life branch never passes. 8.1 and older need an upgrade or the source backport today; failing that, PHP's temporary mitigations or taking the site offline, as the NCSC advises.
  3. Nothing changes and nothing is sent without a person. Each server gets one ticket, worst first, that waits for a yes. Where the A.I.'s reading disagrees with the code, its email is held for a person to rewrite.

We prototyped it and ran it on 24 sample sites for a made-up agency, on 8 sandbox servers. Shown, from the run's own record: 6 sites were already patched, 12 need an update today, and 6 run versions PHP no longer fixes. The run opened 6 tickets, all waiting for a person. It was a simulated run: the code and its rules are real, and the A.I.'s answers were scripted by us, three of them wrong on purpose, the way a spreadsheet misleads.

Those three are the point:

  • The stale note. The sheet said a law firm's server was "Updated to 8.3.36 on Oct 21, per the client's IT contact." The server reported 8.3.30. The A.I. believed the note; the code put the site on today's list.
  • The firewall. For a real estate office behind Cloudflare, the A.I. wrote that "Cloudflare has deployed rules for PHP2Shell on all plans, so it is protected." The code marked it "time bought, not a fix".
  • The backport. A note said a 7.4 server's "Host applies security backports." The code does not take a host's word for an end-of-life branch, and put it on the upgrade-or-offline list.

Our take

The danger on a morning like this is not the flaw you know about. It is the confident row in a spreadsheet that nobody has checked since the last update. An A.I. reading that sheet will be exactly as wrong as the sheet, just faster and more politely.

The useful line for anyone who looks after sites: the version on the server is the only one that counts.

The beat that costs us

It reads version numbers, so it cannot see a fix that a Linux vendor ships inside an old version number. Help Net Security reported that distributions and LTS vendors had the patches before the public release. In our run, one server reports a Debian build of 8.2.29; the code flags it anyway and asks a person to confirm the vendor's build carries the fix. That is slower than trusting the package, and on a morning like this we would rather be slow on one server than wrong on three.

What to do this week

  1. Pull the PHP version from every server you look after, from the server itself, and compare it with 8.5.12, 8.4.27, 8.3.36 or 8.2.35 for its branch.
  2. List every site on 8.1 or older. Each one needs an upgrade, the source backport, PHP's temporary mitigations, or to go offline, today.
  3. Write down which sites sit behind a firewall, and treat that as time bought, not a reason to wait.

If your team looks after client sites and wants a second opinion on how you track them, book a conversation.

Sources