WEEK 44 · DETECTION

Put a two-hour clock on the first report.

Your team can contain a critical CVE in a day and still leave the people who have to make decisions blind for most of it.

Submitted by Neil Watkins

Every critical CVE runs the same experiment, and it always finds the technology you forgot you owned.

I was traveling for business this week, in the company of the people who found PHP2Shell, and I heard about it in real time and in person. Then I waited to see how long my team would take to report it back.

It took 9 business hours. The work itself started right away, and within 8 hours all instances were known, patched, or mitigated. They were slow to report, and they were never slow to act.

By the usual scorecard that's a good week, and I don't want anybody reading it that way. This was remote code execution that an unauthenticated request could trigger, and exploit attempts were showing up the same day the patches shipped. For 9 hours the people doing the work knew where we were exposed, and the person accountable for that exposure didn't. Every decision that belongs above the team waited on that report, from isolating a system the business depends on to telling the business what was happening.

Time is the whole issue here. Nine hours can be catastrophic.

Two weeks before the advisory, Jamie Dimon told Bloomberg that cyber risk at his bank "went up 10-fold" with the newest AI models, and that "AI created vulnerabilities that we didn't know about." Flaws are getting found faster, and attackers read the same advisories we do. What hasn't sped up, at least for us, is how quickly an answer travels from the people who have it to the people who have to decide.

And there were things found. It is in that moment that you find technology in places long forgotten or overlooked, and suddenly it sits in a critical path or can reach a critical asset. A story as old as time itself. Those findings are exactly the ones that change decisions above the team. Anything on PHP 8.1 or older gets no upstream patch at all, and choosing between a vendor backport, an isolation plan and pulling the plug is somebody's call to make with the business, ideally before hour nine.

That has to change, and the fix is unglamorous. A first report that says what we know so far and what we're checking next, sent early and sent incomplete, beats a perfect report nine hours late. Dimon set the right tone in the same interview: "I'm not going to get hysterical," he said, and "what we're doing is rolling up our sleeves and going to work to fix it."

One aside while you're still in it. The third CVE in this batch, CVE-2026-115560, still had no patch as of Thursday, only a workaround that sets session.upload_progress.enabled to 0. Make sure that setting survived every rebuild your team ran this week.

So, here's the MondayMove

Agree with your team this week that the first report on the next critical CVE comes within two hours, saying what you know so far and what you're checking next, whether or not the work is finished.

The next one won't wait nine hours for you.

Friday Follow-Up

The first report will try to be the last one.

A two-hour reporting clock breaks in predictable places, and the first one is the urge to send a finished answer.

Submitted by Neil Watkins

October 30, 2026

MondayMove gives you one concrete action every Monday. FridayFollowUp closes the loop.

Each Friday, a short dispatch on what practitioners actually found when they ran the week's move: where they got stuck, what surprised them, and what to do next. Not sanitized case studies. Field notes. Practitioner to practitioner.

Monday asked you to agree on a two-hour first report before the next critical CVE lands, finished or not.

Nothing has come back from the field yet, so what follows is where I expect the two-hour clock to break.

The first report will try to be the last one. Hour two arrives, and somebody holds the message another twenty minutes because they almost have the answer. Then it happens again at the next check-in, and by hour five the clock has turned back into the old habit with a new name. If "I am working on it" still feels too thin to send, nothing has changed yet.

The report won't have anywhere to go. Normal operations run through tickets, and a ticket is a fine place to do the work and a poor place to tell anyone above the team that the work exists. We had to add a new communication path to close that gap, and I'd expect most teams to find the same hole the first time they try to send the two-hour message and realize nobody agreed where it lands.

The receiving end is the bigger risk. Somebody will answer the first incomplete report by asking why it isn't done yet, and the team will learn in one exchange to go back to waiting. If you sit where I sit, the right reply to an early report is a question about what they need.

"All instances handled" will be the line most likely to be wrong. The sweep finds what your team built. It misses the things you didn't create but use, the PHP that arrived inside a vendor product or an appliance image, and anything on 8.1 or older that no upstream patch will ever reach.

That's the next step. Run one "did we really get it all" pass on PHP2Shell, aimed only at the things you didn't create but use. Pull the list your team built this week, mark every instance that wasn't in your inventory before the advisory, and write down what each one can reach and who owns it now. We built that loop after this week, and it keeps paying long after the last patch ships.

Fast gets you the first report, and the loop is how you get to complete.

Keep going. See what a week can do.

No correct answers here. This is practitioner-to-practitioner. The more honest the responses, the more useful this gets for everyone reading on Monday morning.

See you then.

Discussion