There's a clock nobody puts on the dashboard, and it started running the moment PHP2Shell went public.
Monday put a two-hour clock on the first report. What's worth more time is why a clock belongs there at all, and what it's actually measuring.
I got an early notification on PHP2Shell while I was traveling for business, in the company of the people who found it. That left me holding a question, and it was an honest one. This was not a test. Given how much the landscape has changed, how long would the team take this time to find it, understand it, investigate it, and work to resolve it?
So I waited and watched the clock.
The first day was a mess.
The PHP project posted its advisory on Tuesday and scheduled the fixed releases for Wednesday at 14:00 UTC. Details had leaked ahead of the embargo, so the people hunting for a target had roughly the same head start as the people hunting for a fix. The project rated both flaws 9.2 under CVSS v4, and at least one research team called them a full 10.
Nobody outside the project could say with confidence which versions were affected, and one early estimate reached all the way back to PHP 5.
Mitigation advice contradicted itself in real time. A large edge provider pushed emergency WAF rules to every customer, free plans included, and called them temporary in the same announcement. Researchers floated disabling session upload progress and blocking multipart/form-data requests, the second of which would have broken every form and file upload on the site. A PHP core developer said there were no mitigations at all and the patch was the only fix.
By Thursday a third CVE had joined the first two with no patch behind it, and the session upload progress workaround people had argued about on Tuesday had become the official advice.
One detail deserves its own paragraph. Some of the partial exploit code going around may have been parasitic, written to compromise the researcher curious enough to run it, which is as good a reminder as any that curiosity has an attack surface too.
My team walked straight into that. They started on it right away, and within 8 hours every instance was known, patched, or mitigated. There were things found, the kind you only find in that moment, technology in places long forgotten or overlooked that suddenly sits in a critical path or can reach a critical asset. I can't say more than that.
The report took 9 business hours.
So the work was fast and the word was slow. Those are two different clocks, and only one of them was running anywhere I could see it, which is an uncomfortable thing to admit from the chair that's supposed to see all of them.
When we talked it through afterward, we landed on something that sounds almost too simple to need saying. "I am working on it" is a report. It is key to share, and it is worth more early than a complete answer late.
Our internal comms have to speed up, because the old patterns don’t go fast enough anymore. The team worked the tickets and collaborated through normal operations, and that part worked well. Normal operations move the work along at a steady pace, and nothing about them was ever built to carry the word up the chain fast enough to the people who decide.
Here’s how I think about it now. A critical flaw on an internet-facing system is an availability event. The system is up and serving traffic, and it is also available to anyone who has read the advisory and can craft a request. On a server running mod_php, the request that triggers this one lands before a single line of application code runs.
Finding it, understanding it, investigating it and resolving it are all on the clock the way an outage is on the clock, because for that whole stretch the system is available for exploit.
Exposure is an availability event. From the moment a critical flaw goes public, your system is available for exploit, and every hour before someone who can make decisions knows about it counts the same way downtime does. It is a new key metric for the modern era, and it matters.
We already know how to run outages. An outage gets a start time, a severity, a bridge line and somebody whose job is to send updates to leadership on a fixed cadence whether or not anything has changed. Nobody running a sev 1 waits for the database to come back before sending the first update, because the update is how the people above the bridge make their decisions.
Exposure almost never gets that treatment. The patch SLA starts when the ticket opens, it's keyed to a CVSS score that on Tuesday was either 9.2 or 10 depending on who you asked, and the clock that actually matters, the one that started when the advisory went public, never shows up on anybody's dashboard.
I had a reporting clock before this week. It just wasn't sharp.
In the language of Week 42 it's an outcome-driven metric, and the framework fits it cleanly. The ODM is the measurement, time from first notification to first report and from first notification to every instance known, patched, or mitigated. Monday's two hours are the PLO.
The PLA is where it turns into value, when the business agrees how long it is willing to be available for exploit without knowing, and funds the coverage that makes that number true at two in the morning on a holiday weekend.
Waiting for the full answer feels like professionalism, and that's why the wrong version is so appealing. Nobody wants to walk into a leader's office with half a picture, least of all in a week when the severity score, the affected versions and the mitigation advice all changed inside two days. A complete report protects the person who sends it. A partial one exposes them to being wrong in front of the boss, and most of us learned early that being wrong in front of the boss costs more than being late.
That math worked when the distance between disclosure and exploitation was measured in weeks. It stops working when exploit attempts show up the same day the patch ships, which is exactly what happened here.
Run the same Tuesday two ways.
In the first, the first message up the chain arrives nine hours in and says every instance is handled. In the second, a message arrives inside two hours that says we're on it, here is what we know so far, here is what we're checking, and the last message, hours later, says every instance is handled. The work underneath is identical. In the second version somebody with authority spent seven extra hours able to decide whether to take an exposed system offline or call the vendor that owns it.
Seven hours is the difference between those two Tuesdays, and the team did nothing faster to earn it.
I don't have sage advice. This is vulnerability management, and we've been doing it for decades, and the industry still struggles with it. Now we need to be both fast and complete. In 30 years, nobody can say they are both.
What we changed is smaller than a framework. We added a new communication path, so the word has a way up that doesn't depend on the tickets. We also built a full "did we really get it all" loop that goes looking for the things we didn't create but use, the technology that arrived inside something else and was sitting in a critical path the whole time.
The clock starts at first notification, from any source, and that includes a CISO who happens to be traveling with the people who found the flaw. The first report says "I am working on it," what we know so far and what we're checking next, and it repeats on a cadence until the last instance closes, the same way a sev 1 bridge does.
That changes the work too. A report that goes up early stops being a grade on finished work and turns into a request for help, a decision, an approval, a call to a vendor, while the help can still change the outcome. The status line also gets more honest, because "still checking the last few systems" is a perfectly good update at hour three and an alarming one at hour nine.
It gets hard when the early report turns out to be wrong. A Tuesday report built on Tuesday's facts would have needed correcting by Thursday, on the severity, on the versions and on the workaround. That's fine.
Version the report, say what changed, and keep the clock running. The real failure is a team that gets burned once by a corrected report and quietly goes back to waiting for certainty.
The other hard part is deciding which advisories start the clock at all. A team that sends a two-hour report for every CVE trains leadership to skim them, so start with the narrowest definition you can defend, critical and internet-facing with exploit code in public, and widen it once the report becomes routine.
The next one is already on somebody's screen, so start the clock.