עברית

The win: on 2026-10-21 the PHP project shipped fixes for two critical remote-code-execution flaws, nicknamed PHP2Shell, around 09:30 ET. By 12:21 our production trading platform was running the patched build. The production step took 25 seconds, and a health check that hit the live trading API once a second saw zero failures while it happened. Before production, every other PHP machine we run had already been patched (or, where a vendor lagged, mitigated), verified and health-checked, starting with development. By the end of the day, all 11 servers and 16 Drupal installations (production, staging and development) were serving on the fixed builds, covering 7 of our live Drupal sites and apps.

Nobody stayed up all night for this. The work was done by our AI operations team, a set of specialist AI agents with a human (our founder) deciding at the gates. Here is how it went, what we checked, and what we changed afterwards so it goes even faster next time.

What PHP2Shell was

PHP2Shell is two flaws in the PHP core, CVE-2026-109618 and CVE-2026-109619, rated CVSS v4 9.2 (critical). Both allow remote code execution. The details leaked publicly on 2026-10-20, a day before the coordinated patch, so attackers had a head start, and security firms soon reported exploitation attempts in the wild. The fixed releases were PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For the technical deep dive, see Wiz's write-up of PHP2Shell.

A leaked critical RCE in the language that runs your websites leaves you no time for meetings.

The timeline (EDT, 2026-10-21)

1. ~12:00 Our founder sends one instruction: "Find read patch all fleet immediately."
2. Minutes later The operations agents finish an inventory of every machine running PHP, across Ubuntu's own packages and a third-party PHP repository.
3. Shortly after 12:00 to 12:21 The rollout runs in a fixed order: development first, then the rest of the fleet, and production last. Each step is verified before the next starts.
4. 12:21:05 to 12:21:30 Production is patched in 25 seconds. A health check polls the live trading API once per second throughout, and every check passes.

We read the changelog, not the version number

Distributions often fix a security flaw by backporting the patch into an older version, so two machines showing the same version number can differ in whether they are actually fixed. A version string doesn't settle the question.

So the agents read the package changelog and confirmed it contained the fix for these two CVEs before anything was installed. Every machine was then checked three ways: the package version, the service running, and the sites answering normally. "The command exited OK" didn't count.

Then we went looking for trouble

Patching closes the door. It doesn't tell you whether someone walked through it first, and the exploit had been public for about a day. So the cybersecurity agent ran a read-only compromise hunt across the whole fleet, looking at:

• process trees and unexpected child processes of the web server;
• crash signatures typical of memory-corruption exploits;
• access-log patterns associated with this class of attack;
• file integrity in web roots;
• persistence (scheduled jobs, startup entries, new accounts);
• outbound connections.

Result: no evidence of compromise. We also wrote down what the hunt could not see. Some techniques, such as implants that live only in memory, wouldn't show up in a read-only hunt like this. An honest "nothing found" states its blind spots.

Where a vendor was slower, we mitigated

A small minority of our sites use a third-party PHP repository whose fixed packages hadn't reached its mirror yet. For those we applied the official interim mitigations within minutes and set an automatic loop to install the fixed packages as soon as they appeared. When the vendor's download mirror kept failing under the global rush, the operations agent finished the upgrade by hand, one site at a time. Those sites have since been patched.

What we changed so next time is faster

Our rule is that every incident has to leave the system better than it found it. This one left four changes:

1. Auto-patching now covers third-party package repositories, not just the distribution's own. That gap, plus a vendor mirror that buckled under the rush, is why a few sites had to wait.
2. A stuck-update watchdog. Package updates can hang quietly and block every later update. We now detect that and alert on it.
3. A CVE feed watcher is on the way, so critical advisories for software we run reach the agents without anyone having to read the news first.
4. A critical-runtime runbook: this exact sequence (inventory, read the changelog, dev-first rollout, a production health poll, a compromise hunt, mitigation where needed) written down so any agent can run it.

How an AI ops team actually does this

There was no magic, just structure:

• One orchestrator turns the founder's instruction into work and decides the order.
• Specialists do the work: a sysadmin agent runs the rollout, a cybersecurity agent runs the compromise hunt, the site maintainers verify their sites, and QA checks the evidence.
• A human decides at the gates. The founder starts the response and approves anything that touches production or carries risk. The agents do the reading, checking and typing, quickly and without skipping steps.

The speed came from preparation: knowing what we run, checking the right evidence, and following a fixed order with production last.

From the alert to this write-up, it all happened the same day: triage, patch, verify, hunt, and then this post and its video. The same agent team did all of it, with a human approving each gate.

Our sites

These are the sites in our family. Every one that runs on our PHP stack was patched the same day.

• drupaldeveloper.us: Drupal 11 upgrades, Drupal 7 rescue and security hardening
• god of bots: meet the AI agent team behind this response
• buzzwords.technology: technology buzzwords explained, demystified and curated
• buzzwords.news: AI news analysis, protected by U.S. Patent No. 11,232,363
• buzzword.today: the one word the news can't stop saying today
• worldsituation.com: how the world's news feels right now, as one number
• foodtron.org: recipes, food news and culinary inspiration
• hamishkan.net: Jewish recipes, traditions and culinary heritage
• robotrader.io: our AI-operated trading platform

Want the same for your servers?

We run Drupal and LAMP estates with this same AI-assisted operations model: patching on the day a fix ships, evidence instead of assumptions, and a human approving anything risky. If a critical PHP or Drupal advisory would leave your team scrambling, we can take that off your plate.

Talk to us about managed Drupal / LAMP operations · See our services

Further reading: god of bots: the bot team behind this response · $244K Later: Why We Left AWS for Our Own Hardware

Sources: Wiz: PHP2Shell technical write-up · Huntress: rapid response · SecurityWeek: leaked critical PHP flaws · Sansec research