On a Saturday in late September, we patched our remote-access gateways. Routine stuff. A vendor had published fixes for two critical vulnerabilities, CVE-2026-88771 and CVE-2026-88772, and we pushed the fixed build to both nodes that afternoon. Ten minutes of downtime. Nobody noticed.
About 23 hours later, the attackers showed up.
Some background. These two bugs weren't new to the attackers. They were already being exploited as zero-days before the vendor published a fix. The bad guys had a head start. The patch was the vendor catching up, and the rest of us catching up after that.
A few weeks ago, I published a white paper on what I call the AIMO, the AI Management Office. One of the numbers in it is Mandiant's time-to-exploit, which measures how long it takes attackers to exploit a vulnerability after it's disclosed. In 2018 it was 63 days. By 2023 it was five. Then it went negative. Negative one day in 2024, and an estimated negative seven days in 2025.
Negative. Think about that for a second. On average, attackers are now exploiting vulnerabilities a week before the fix exists.
I wrote that as a prediction about where things were headed. This month it showed up at our front door.
It's worth walking through how it played out.
A week earlier, someone swept our logon page. Reconnaissance. The same sweep touched a lot of other organizations that day. Then the patch. Then, the next day, a probe from the campaign's first toolset checked our version, saw we were patched, and moved on. Polite, really.
The next morning a second toolset arrived. This one didn't bother checking versions. It just fired. Two exploitation attempts, one minute apart. Both failed. To the gateway they looked like a couple of bad logins.
So, good news. But here's the thing. Patching wasn't the end of the story. It was the start of a different one.
A patch closes the door. It doesn't tell you whether someone walked through it before you closed it. When time-to-exploit is negative, you have to assume the door was open for a while. The question the morning after wasn't "are we patched?" It was "were we already in trouble?" That's not a patching problem. That's an incident response problem.
And it's about to get worse. Look at the shape of this campaign. Weaponized exploits before disclosure. Two toolsets, one careful and one not. Synchronized waves across many targets, with fresh servers and fresh tools mid-campaign. That's a well-run operation built by humans. Now give that operation frontier AI. Models are getting very good at finding bugs and writing exploits. Negative seven days is the number before the machines really get going.
Which means every critical patch comes with a homework assignment. Were we hit before we patched? Did anything land? Did anything phone home? For us that meant 30 days of gateway and firewall logs, vendor scanners, support bundles, process checks, and a hard look at every outbound connection. Nothing landed. Nothing phoned home. Closed, no evidence of compromise.
So, here's the question. What's your IR program?
For a lot of organizations, it's a shiny red button behind glass. There's a binder. There's a retainer with a firm you've never called. Everyone hopes they never have to press it, and nobody's quite sure what happens when they do.
The other version is a routine. A process you've run so many times it's boring. You know which logs you have and how far back they go. You know who pulls the support bundle and who checks the firewall. A clean result means something because you've seen what a dirty one looks like.
Guess which one is the future.
The skeptic says: you're a vendor, of course you want me to buy more instrumentation and more IR capability. Perhaps. Some of you will need to. But it starts with process, not procurement. If every critical vulnerability is a possible breach, IR stops being an emergency and becomes a regular part of operations. Run the process first. It'll tell you what you're missing. You don't want your first real run to be the one that counts.
A few questions worth asking this week. When a critical fix drops for an internet-facing system, does anyone automatically ask, "were we hit before?" Do you have enough logs, kept long enough, to answer that honestly? And when did you last actually run the process, not just read it?
When the attackers showed up, we didn't go looking for the binder. We already had the logs, the tools, and the people who knew what to do with them. That's not luck. That's instrumentation.
Be prepared.
Researched and drafted with Claude, which should surprise exactly no one given who I am. The arguing and editing are mine.