Zero-Day Exploitation Is Accelerating. Your Patching Program Must Become an Exposure-Reduction Program

What the latest exploitation data actually says

Recent analysis shows a clear trend: attackers are exploiting a growing share of vulnerabilities on or before the day a CVE is publicly published—the practical “zero-day / one-day” window defenders used to assume they had time to handle.

Key datapoints from 2025 analysis:

• 884 known exploited vulnerabilities (KEVs) had first-time exploitation evidence reported during 2025.

• 28.96% of those KEVs were exploited on or before the day the CVE was published, up from 23.6% in 2024.

• The most frequently targeted categories included network edge devices (firewalls, VPNs, proxies), followed by content management systems and open source software.

For this research, they treat “zero-day” as exploitation evidence published on or before public disclosure—a pragmatic, defender-relevant definition.

The implication is simple: for a meaningful chunk of exploited vulnerabilities, your first realistic chance to respond is the moment the world learns about it—and sometimes attackers are already ahead.

Why “patch faster” is not a plan

“Patch faster” is a slogan. It collapses under real-world constraints:

• Operational risk: you cannot emergency-patch everything without breaking revenue systems.

• Asset sprawl: you cannot protect what you cannot see—especially across cloud, endpoints, web apps, SaaS, and remote access.

• Exploit asymmetry: attackers only need one exposed, reachable weakness; defenders must manage thousands.

So the correct goal is not “patch everything quickly.” The goal is:

Shrink the exposure window for what attackers actually exploit.

That requires two things you can measure:

1. Time-to-awareness (how fast you know you’re exposed)

2. Time-to-remediation (how fast you remove or neutralize exposure)

You cannot manage either without a tight loop from vulnerability discovery → exploitation signals → prioritization → remediation execution → verification.

The shift: vulnerability management → exposure management

Vulnerability management programs that stay stuck on CVSS-only queues lose because exploitation is not evenly distributed. Even VulnCheck’s broader exploitation trend reporting shows that while the total volume of CVEs is massive, the slice that becomes publicly reported “exploited in the wild” is the set that drives urgent operational risk.

A modern program focuses on:

• Exploitability evidence (KEV / in-the-wild exploitation signals)

• Reachability and exposure (internet-facing, identity-adjacent, remote access, edge devices)

• Blast radius (lateral movement potential, privileged paths, business-critical systems)

• Remediation feasibility (controls, compensating mitigations, rollout sequencing)

That is the CTEM mindset in practice: continuous prioritization based on current threat and exposure, not static severity labels.

What to do this week: a zero-day-ready operating cadence

1) Treat internet-facing edge as a separate risk tier

Edge tech is repeatedly overrepresented in mass exploitation: VPNs, firewalls, proxies, remote access, gateways.
Operate that tier with different rules:

• accelerated patch SLAs

• emergency change windows

• configuration hardening baselines

• aggressive exposure reduction (disable unused services, restrict management planes, geo/IP controls)

2) Build an “exploitation-first” queue, not a “severity-first” queue

Your top queue should be: “exploited-in-the-wild / KEV / credible exploitation evidence.”
That’s the list that compresses your decision timeline from weeks to hours.

3) Measure MTTR and SLA performance like an operational KPI

If you cannot answer, weekly:

• median time to remediate exploited vulnerabilities

• SLA compliance by business unit / application owner

• backlog age distribution (especially for externally reachable assets)

…then you are managing tickets, not risk.

4) Pre-authorize compensating controls for when patching is blocked

Zero-day response fails when patching is impossible immediately. Pre-approve controls such as:

• WAF / virtual patch rules

• segmentation and ACL restrictions

• disabling vulnerable features/modules

• identity controls (MFA enforcement, conditional access tightening)

• EDR detections and threat hunts focused on active exploitation TTPs

5) Close the loop with verification

“Patched” is not the end state. “Verified not exposed” is the end state.
Verification needs rescans, configuration checks, and proof for audit/insurance conversations.

Where most programs break: visibility and prioritization lag

Even if you have scanners and ticketing, two lags kill you:

• Lag #1: CVE lifecycle and enrichment delays
  A CVE is a standardized identifier, not a remediation plan. CVEs move through assignment and enrichment steps, and downstream systems vary in how quickly they reflect usable details.

• Lag #2: exploitation intelligence not tied to remediation execution
  Many teams see “exploited” headlines but don’t have the workflow to immediately answer:
  “Are we exposed? Where? Who owns it? What’s the fastest safe fix?”

This is where a purpose-built vulnerability and threat management approach changes outcomes.

InfoSight’s perspective: operationalize exploitation signals into verified fixes

At InfoSight, the point is not to produce another vulnerability report. The point is to:

• identify where you are exposed across your real environment

• prioritize what matters based on threat and exploit signals

• drive remediation with measurable MTTR and SLA performance

• verify closure and document evidence

That is why Mitigator is built around dashboards and workflows that connect vulnerability data to action: risk visibility, prioritized remediation, and performance measurement—so teams stop reacting to headlines and start running a repeatable exposure-reduction cycle.

If you want a practical benchmark: take your last “critical” vulnerability push and ask one question—how many of those items would still be ahead of a queue built around known exploitation and exposure? That delta is wasted effort and false confidence.

Bottom line

Zero-day/one-day exploitation is not a rare edge case anymore. A material share of exploited vulnerabilities are being used at disclosure time or earlier, especially against high-leverage, internet-facing technologies.

The winning posture is not “patch everything.” The winning posture is: see exposure fast, prioritize exploited risk, execute remediation with discipline, verify closure, measure MTTR.