The Window is Already Open
Your monthly patch cycle has a name in attacker circles: the window. AI has made patching predictable, CVSS-sorted queues obsolete, and exploit probability the only prioritization that still works.
Your monthly patch cycle has a name in attacker circles. They call it the window.
Not a vulnerability window. Not a remediation gap. A guaranteed, calendar-confirmed window — because AI has made your patching schedule predictable, and predictable defenses are the easiest kind to plan around.
Google Threat Intelligence Group confirmed it in March 2026: 48% of all zero-day exploits now target enterprise-grade technology. That’s a record high. And the driver isn’t more sophisticated attackers, it’s AI doing the discovery work that used to take human researchers days or weeks. The time between vulnerability disclosure and active exploitation in the wild has collapsed. Not shrunk. Collapsed.
The targets aren’t random. Attackers are running AI-assisted analysis against the exact infrastructure APAC enterprises rely on for cross-border operations — internet-facing appliances, VPN gateways, remote access controllers. Citrix. Fortinet. Ivanti. Palo Alto. The attack surface is well-documented, widely deployed, and, in too many environments I’ve walked into, running behind a CVSS-sorted patch queue that gives it a false sense of order.
How this looks from the CFO’s chair
Your security team is working through a backlog of 300 open vulnerabilities in priority order. They’re doing exactly what the process says. Meanwhile, an attacker’s AI model has already identified the one CVE on that list that’s internet-facing, has a working exploit in circulation, and maps to your remote access stack. That CVE is ranked somewhere around position 47 — “medium severity, no active exploitation reported at time of assessment.”
It gets exploited. Not because your team was negligent. Because the prioritization model was built for a world where attackers moved at human speed. That world ended.
The remediation cost for a targeted breach of this kind in APAC financial services is no longer a hypothetical. I’ve seen organizations spend north of $3M in incident response, regulatory disclosure, and infrastructure rebuilding after exactly this sequence of events. The vulnerability was known. The patch existed. The queue just hadn’t reached it yet.
AI didn’t invent zero-day exploitation. It industrialized it.
The mechanism is straightforward: large language models, trained on security research and public CVE data, can now analyze newly disclosed vulnerabilities and generate working proof-of-concept exploits in hours, not days. Combine that with automated scanning tools that identify which organizations have the affected asset exposed to the internet, and you have a targeting pipeline that runs faster than any human patch cycle can match.
The underlying logic flaw in our defenses is this: CVSS scores measure theoretical severity. They don’t measure attacker preference. A CVE rated 7.8 that affects a widely deployed, internet-facing appliance with a public exploit available is infinitely more dangerous than a 9.5 rated vulnerability that requires authenticated local access in a non-default configuration. CVSS was never built to make that distinction. We used it anyway, because it was the number we had. (And most teams still don’t have an alternative in their workflow.)
The technical detail that matters here: the EPSS score — Exploit Prediction Scoring System, maintained by FIRST.org — does what CVSS cannot. It calculates the probability that a given CVE will be exploited in the wild within 30 days, using real-world exploitation data. It’s free. It’s updated daily. And it changes the patch queue entirely when you run your open CVEs through it.
A best-run program that still kept firefighting
I sat in a briefing room with the security leadership team of a regional BFSI — multi-country presence across Southeast Asia, one of the better-run programs I’ve seen at that scale. They weren’t cutting corners. Their patch cycle was documented, governed, and followed. CVSS scores drove the queue: critical and high got immediate attention, medium sat in the backlog, low barely registered. By every internal metric they were tracking, they were compliant and in control.
They also had a BAS platform in place — and I want to be fair here, because the intent was right. They were using it to validate whether their controls could detect and block known attack techniques. That discipline matters. But the BAS assessments were passing scenarios their library already knew about. What they weren’t measuring was whether their attack surface was visible in the first place.
That was the actual problem. A best-of-breed environment built over years of acquisition and regional expansion — different endpoint vendors across different markets, network appliances that varied by country, cloud workloads running alongside legacy on-premises infrastructure. The security team was patching what they could see. What they couldn’t see, they couldn’t prioritize. And what they couldn’t prioritize didn’t appear in the CVSS queue at all.
They continued to firefight breaches through vulnerabilities. Not because they were negligent. Because the model they were using to measure risk had no mechanism to surface what it couldn’t inventory — and the vulnerabilities being exploited weren’t the ones at the top of the CVSS list. They were mid-range scores, internet-facing, with working exploits in circulation that the team had deprioritized because the number said they could wait.
The BAS tool gave them a green dashboard. The attackers had a different dashboard entirely.
What to do this week
Pull your current open CVE list. Cross-reference every item against EPSS scores — you can query the FIRST.org API directly, or if you’re running Tenable, Qualys, or Rapid7, this is already available inside your existing platform (Tenable calls it Predictive Prioritization; Qualys surfaces it through TruRisk).
Filter for two conditions simultaneously: internet-facing assets AND EPSS score above 0.5. That 0.5 threshold means a greater than 50% probability of exploitation in the wild within 30 days. Anything that clears both filters goes to the top of the queue — regardless of CVSS rating. That is your actual threat-informed patch list.
If you don’t have an exploit prediction layer in your vulnerability management workflow yet, that is the gap to close before anything else. Not a new tool category. Not a budget conversation. An existing capability inside platforms most teams already own, sitting unused because nobody changed the prioritization model.
The architectural rethink here is moving from audit-and-remediate to predict-and-automate. That means AI-driven prioritization feeding directly into automated patching pipelines for tier-1 assets, attack surface management that accounts for ephemeral workloads and AI agent identities (more on that in a separate post — it’s its own crisis), and red team exercises designed specifically to test time-to-patch against simulated AI-accelerated exploit development.
I’ll be honest about where I haven’t found a clean answer: legacy appliances. If you’re running end-of-support Citrix or Fortinet gear that can’t be patched without a maintenance window, and that maintenance window requires coordinating six teams and a change freeze exception, you’re not eliminating risk — you’re managing it. The honest position is to treat those assets as compromised-until-proven-otherwise and build detection and isolation around them, not just a patch ticket with a future due date. I don’t have a better answer than that for those environments. Yet.
The bottom line
AI didn’t just accelerate the attack. It made your current defense strategy obsolete.
The question
For those of you who’ve moved to exploit probability scoring — EPSS or a commercial equivalent — what changed most in how your team actually operates? I’m specifically curious whether it shifted the conversation with the business, or whether it stayed a SOC-level change.
Reference: Google Cloud — 2025 Zero-Day Exploitation Analysis
← All writing