PHP2Shell: Emergency Patch Window

The situation

At 01:30 ET, PHP announces an out-of-cycle security release for two critical vulnerabilities rated CVSS 9.2. The notice names no component, no affected versions, and no workaround. Your inventory says you run 42 PHP pools. Your inventory is 58% complete. The exercise starts there.

1. The inventory disagrees with itself
   The asset register, the hosting providers, and the running processes tell three different stories about what your estate actually serves. Until the room reconciles them, every later decision is built on a guess.
2. A weaponized exploit claim lands — unverified
   A detailed root-cause post and a downloadable exploit framework circulate widely. Nobody independent has reproduced the chain. Treat it as proven and you may break production on a rumor; wave it off and you may ignore the real thing. The disciplined path prices it as a planning input and validates it in isolation.
3. Multipart probing and worker crashes at the edge
   Telemetry shows suspicious traffic and dying workers. It is consistent with exploitation. It is also consistent with noise. The room has to act before it can know.
4. The revenue argument against emergency changes
   Every emergency change carries its own risk, and the business case against touching production mid-incident is genuinely strong. So is the case for moving. Someone has to own the trade-off — out loud, on the record.
5. Vendors, hosts, and the pool that can never be patched
   Providers will patch "when published." One vendor answers "under evaluation." And the end-of-life pool cannot be patched at all: isolate it, gateway it, or migrate its last application — under deadline pressure, with a named owner.
6. The advisory lands: ground truth, at last
   The official release names the affected branches, the component, and the fixed versions. Some overnight claims were right. Some were wrong. The room has to say which — explicitly — because teams that cannot say what they got wrong cannot price their next emergency either.
7. "Patched" on the dashboard, unpatched in the process table
   The package update completes and the version string reads fixed. The old FPM master never restarted, and a slice of traffic still routes to the old container image. A version string is a claim, not evidence. Only the processes and the traffic can settle it.
8. A php-fpm worker spawned curl at 03:12
   Hours before the advisory, a worker on the legacy pool reached out and wrote a file that is no longer there. This is no longer only a patching exercise — and rebuilding the worker before scoping what it touched would destroy the evidence and possibly keep the intruder.
9. The largest customer asks the only question that matters
   "Were we exposed? Was any of our data on the affected systems?" The honest answer is narrower than either reassurance or alarm — and a flat "you were not affected" today becomes tomorrow's exhibit if the scoping changes.

Who's in the room

Eight roles, each optimizing for something real — and not the same thing. AI characters fill any seat your team doesn't staff, and play their brief at full strength.

What gets practiced

The scenario is scored across seven dimensions — evidence discipline, runtime inventory quality, interim-mitigation judgment, patch execution and verification, containment and scoping, stakeholder communication, and dissent handling. These are the muscles it works hardest:

Format

A facilitated tabletop exercise run live on TableX — one session, decisions in real time, every decision and its evidence recorded as you go.

The real event behind it

This is not a hypothetical. The exercise is built directly on the PHP security event of October 21, 2026 — announced, leaked, argued about, and resolved in public, in roughly the order the scenario runs it.