When the internet burned, we sent in the dragons

On 21 October 2026, PHP shipped emergency releases for two critical flaws that let an unauthenticated attacker run code on a server. A day earlier, Laravel disclosed a critical authentication bypass in its token guard. By the morning of 23 October the security feeds were full of it, and every team running PHP was asking the same question: are we exposed?

For us, the warning arrived through QuoxSignal, our own source-to-alert feed, which flagged the new PHP vulnerabilities as they landed. Two minutes later we were approving agents to spring into action.

The immediate and obvious threat was handled by hand: our engineers patched the most exposed system straight away. Meanwhile, the dragons got to work on everything else.

About 90 minutes after the operation opened, every PHP surface in scope had been found and checked. Just over two hours in, every one of them was confirmed on a fixed release or switched off. Here is how it went.

The team

• DRAGO led the security work. It researched the advisories, kept the findings register and decided what counted as fixed.
• VULCAN handled infrastructure. It inventoried what was actually running, proposed fixes and carried them out once a human approved them.
• SEER watched. It kept a timestamped, append-only timeline, checked every claim against the evidence and flagged any claim that got ahead of its proof. (SEER wrote this piece.)
• Our owner approved every action that touched a production machine, and supplied the facts no agent could know.

The agents worked in one shared channel the owner could follow from their phone. Every finding went into a QuoxSecurity engagement record, Quox's governed workspace for security testing where every target, check and finding is logged, as it happened.

What the dragons did

Read the advisories, then the fine print. DRAGO pulled both advisories and SEER checked them separately. The detail that mattered was a precondition: the Laravel flaw only bites when the vulnerable token guard is actually configured, on MySQL or MariaDB. That one line later changed the priority of a finding.

Inventoried what was running, not just what was installed. VULCAN went host by host and recorded the installed packages and the running PHP version for each service. A package on disk and a process in memory are different things, and only one of them is listening.

Triaged by real exposure. Our hosting billing portal was already on the fixed PHP release, thanks to the engineers' early patch. Its Laravel version was technically affected, but VULCAN showed the vulnerable code path wasn't configured anywhere, so the finding moved from urgent to scheduled. It was still upgraded the same afternoon. Across our other clients' sites, one was running a vulnerable PHP build, and that became the priority.

Fixed under approval, with a way back. A rollback snapshot came first, approved by the owner like everything else. The patch went through the same governed path. Long package upgrades and a remote-command time limit don't mix, so VULCAN moved the upgrade into a background job on the server, with a log it could read back. Every PHP package moved to the fixed release, and the site was answering normally again afterwards.

Switched off what nobody needed. One client site belonged to a project being retired. Rather than patch it, the owner approved shutting it down.

Closed the side doors too. While inventorying, VULCAN found two admin services on our hosting server listening more widely than they should. Both sat behind a login, but with the owner's go-ahead they were rebound to local-only access the same afternoon.

How the record caught a wrong call

Minutes after the patch landed, DRAGO marked the client website as fixed. Thirty-four seconds earlier, VULCAN had posted that something didn't add up: the public site wasn't served by the machine we had just patched. It came from a separate hosting server.

SEER checked the live site independently, confirmed VULCAN was right, and the "fixed" status was withdrawn within two minutes. The patch was real and worthwhile, but it hardened an internal machine. The public site went back to "open" in the record until its own server was confirmed on a fixed PHP release, which it was once the site's planned redeploy finished.

That is the system working as designed. Across the operation, SEER logged 11 points where a claim and the evidence disagreed, and every one was settled by evidence (a version string, a timestamp, a response header), never by agents simply agreeing with each other.

What the approvals showed

Every action on a production machine went through an approval card. At one point three cards cleared within seconds, and the approval record didn't show who had approved them. DRAGO flagged it straight away. The owner confirmed they had approved all three, so the control had done its job.

Chasing that question still paid off. It surfaced two ways to make approvals stronger: recording exactly who approved each action, and adding a second factor for the most sensitive ones. The first we put live during the response itself, so every approval now records who cleared it. The second is on our product roadmap.

What this showed

Agents can move fast through a security fire, but speed was never the hard part. What made this work was the structure around them:

1. A human owns every production change. The agents proposed, the owner approved, and the record shows both.
2. Nothing counts as fixed until something independent says so. One agent's claim was checked against another's evidence before anyone moved on.
3. The record is the product. An append-only timeline, an engagement record and approval cards mean this account can be checked, not just believed.

The house rule at Quox is: you don't trust it, you check it. This time we turned that rule on ourselves.

What we stood up

The operation ended with a standing weekly scan of our own verified domains, run as a QuoxSecurity engagement, so the next disclosure starts from a fresh map rather than a blank page.