TL;DR: Patch backlogs are giving attackers a wider window to exploit older flaws, and Coalition reports that vulnerability exploitation became the leading initial access vector in 2025, accounting for 31% of all breaches. Security teams now need prioritised remediation based on exploitability and exposure, not equal treatment for every CVE.
At a glance
What this is: Coalition argues that slower remediation and exposed older flaws are letting attackers return to resurgent vulnerabilities, with exploitation now the leading initial access path in its cited breach data.
Why it matters: For IAM and security teams, the lesson is that access exposure and patch backlog management are now linked problems: delayed remediation extends the life of exploitable paths into systems, accounts and hosted environments.
By the numbers:
- Vulnerability exploitation was the leading initial access vector in 2025, accounting for 31% of all breaches.
Context
Patch governance is a prioritisation problem, not just a hygiene problem. When the volume of disclosed vulnerabilities outstrips patching capacity, older flaws remain live long enough for attackers to return to them after the first disclosure wave has passed.
In identity-adjacent environments, that same delay can preserve access paths into admin consoles, hosting control planes and third-party-connected systems. The article’s examples show that exposure management fails when organisations treat every CVE as equally urgent or assume older issues have already faded from attacker interest.
Key questions
Q: What should teams do first when an older vulnerability becomes active again?
A: Start with exposure validation, not patch theatre. Confirm which assets are actually reachable, whether the vulnerable service is internet-facing, and whether exploit activity is already present. Then prioritise containment for the instances that can be touched remotely or that protect high-value control planes. The goal is to remove the attacker’s easiest path before expanding into broader remediation work.
Q: Why does delayed patching continue to create risk even for older, well-publicized vulnerabilities?
A: Delayed patching keeps known attack paths open long after a flaw becomes public. Attackers do not need novelty when widely exploited vulnerabilities still appear in inboxes, documents, and exposed systems. If defenders are slow to close those gaps, the same CVE can keep enabling malware delivery, persistence, and follow-on compromise across many environments.
Q: What are the signs that a vulnerability prioritization model is failing?
A: The clearest signs are long delays on known exploited vulnerabilities, tickets that lack ownership, duplicate findings across tools, and high-severity work that never maps to real attack paths. If the team keeps closing urgent-looking items without reducing exploitable exposure, the model is measuring activity rather than risk reduction.
Q: How should security teams handle shared responsibility for hosted software?
A: Teams should define who patches, who confirms success and who communicates residual risk before the issue is found. If a provider manages the platform, internal teams still need verification, escalation paths and a clear view of which assets remain exposed. Shared responsibility without explicit ownership is just delayed accountability.
Technical breakdown
Why resurgent vulnerabilities remain exploitable long after disclosure
A resurgent vulnerability is a flaw that gets attention at disclosure and then reappears later because exposure remains in the field. The mechanism is simple: attackers monitor for unpatched instances, exposed management interfaces and lagging remediation, then revisit the same issue when defenders have moved on. This is especially effective when the affected technology sits on a control plane or gateway that opens broad downstream access. In practice, the risk is not just the CVE itself but the persistence of reachable instances across forgotten assets and third-party-hosted environments. See the Zero-Day and Exploited Vulnerabilities Guide.
Practical implication: Use exposure data, not age alone, to decide whether an older vulnerability still needs active containment.
How platform-level aggregation turns one flaw into many affected organisations
Aggregation occurs when a single platform, hosted service or widely deployed component concentrates risk across many customers at once. The same root cause can affect a much larger population than a standalone server vulnerability because the trust boundary sits upstream of the customer. In these cases, patching responsibility may be split between the customer and the provider, which slows action and creates ambiguity about who must verify remediation. That ambiguity is itself a governance weakness because the delay extends the attacker’s usable window. See the Vulnerability Management Guide.
Practical implication: Assign clear ownership for hosted platforms and verify who actually controls remediation before exposure becomes widespread.
Why third-party access can escalate faster than a zero-day
The Vercel example shows that attackers do not need a novel exploit when they can abuse legitimate access paths. A third-party tool, broad OAuth permissions and subsequent credential theft can produce lateral movement without touching the vulnerability lifecycle at all. That shifts the security problem from patching alone to the governance of delegated access, connected accounts and tool trust. For identity teams, this is a reminder that third-party access can become an initial access vector when permissions are broader than the task requires. See the Just-in-Time Access and Zero Standing Privilege Guide.
Practical implication: Review delegated access, OAuth grants and connected apps with the same urgency you apply to exposed software.
Threat narrative
Attacker objective: The attacker’s objective is to turn stale exposure into reliable access across valuable systems, often by combining old flaws with delegated trust and broad platform reach.
- Entry occurs when attackers find exposed, unpatched or broadly reachable software and management interfaces, then revisit flaws that were disclosed months earlier.
- Credential or access abuse follows when the attacker uses legitimate permissions, control-plane access or weakly governed third-party connections to move deeper into the environment.
- Impact appears when a control plane, customer environment or downstream hosted system is reached at scale, extending the breach beyond the original exposure point.
Breaches seen in the wild
- Commvault Metallic breach 2025: A nation-state actor exploited a Commvault zero-day in Azure and may have taken app secrets that open customers' Microsoft 365 tenants.
- United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Exposure windows, not disclosure dates, now define vulnerability risk. Older flaws remain dangerous when remediation lags and exposed instances stay reachable. That makes backlog age a poor proxy for actual safety, especially where management interfaces or hosted control planes are concerned. Practitioners need to treat live exposure as the governing variable, not publication history.
Delegated trust is becoming the hidden accelerant in vulnerability-driven incidents. The Vercel case shows how third-party access, OAuth permissions and downstream credential theft can turn a non-exploit event into broad compromise. That makes just-in-time access and zero standing privilege relevant beyond classic privilege design, because standing trust in connected tools widens the attack surface even when no CVE is involved.
Patch prioritisation has become a governance discipline, not a maintenance task. Once attackers begin revisiting older flaws at scale, the deciding factor is which exposures remain reachable and business-critical, not which tickets arrived first. That is why vulnerability management, identity governance and external exposure monitoring now need to operate as one control conversation.
Platform concentration creates blast radius that conventional per-asset patching cannot absorb. When a single vendor, hosting layer or shared control plane aggregates many customers, remediation speed becomes only one variable. Practitioners must also understand shared responsibility, third-party accountability and the trust chain that determines whether an exposed issue can be exploited across many downstream environments.
Resurgent vulnerability management is the right framing for this category of risk. The field needs a concept that captures how dormant CVEs become active again when visibility, exposure and patch latency align. The operational conclusion is simple: stale issues are not historical issues if attackers can still reach them.
From our research library:
- The median time to fully patch a vulnerability in CISA's Known Exploited Vulnerabilities catalog rose to 43 days, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: Vulnerability Management Guide
What this signals
Resurgent vulnerability management: the critical issue is not whether a CVE is old, but whether exposed instances still exist and can be reached by attackers. Organisations that measure risk by disclosure date alone will keep missing the second wave of exploitation, especially on internet-facing control planes and shared hosting layers.
The governance gap is ownership drift: provider-managed platforms, third-party tools and distributed infrastructure make it easy for remediation responsibility to become ambiguous. That ambiguity slows response, extends exposure and gives attackers more time to return to vulnerabilities that defenders thought had aged out of relevance.
The operational answer is tighter prioritisation between exposure, exploitability and business reach, supported by external threat signals and verification loops rather than ticket counts alone. That is the control posture that reduces the life of a vulnerability after the first disclosure has passed.
For practitioners
- Prioritise exposed vulnerabilities over inventory age Use external exposure, exploit evidence and asset criticality to rank remediation instead of treating all backlog items equally.
- Review third-party access paths and OAuth grants Identify connected applications, delegated tokens and broad permissions that could be abused without a software exploit.
- Separate hosted and self-managed remediation ownership Document who patches, who verifies and who escalates when a vulnerability sits inside a provider-managed platform.
- Hunt for renewed exploitation after disclosure Re-check telemetry, honeypot signals and internet-facing assets after the first alert wave has passed, especially for high-reach control planes. See the Zero-Day and Exploited Vulnerabilities Guide.
Key takeaways
- Older vulnerabilities can become active threats again when remediation lags and exposed instances remain reachable.
- Coalition cites 31% of all breaches in 2025 as starting with vulnerability exploitation, underscoring how often old flaws still matter.
- The most effective control is not blanket patching speed but exposure-led prioritisation tied to ownership, verification and exploit evidence.
Related NHI Mgmt Group resources: Zero-Day and Exploited Vulnerabilities Guide · Conditional Access Guide · Vulnerability Management Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article describes exploitation and credential-enabled pivoting as the core attack pattern. |
| Recommendation — Map resurgent vulnerability activity to credential access and lateral movement to prioritise detection and containment. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and systems are monitored to detect potential cybersecurity events | Honeypot monitoring and renewed exploitation detection are central to the article’s threat picture. |
| Recommendation — Use continuous monitoring to detect renewed exploitation of previously disclosed vulnerabilities. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The piece is fundamentally about backlog prioritisation, exposure and remediation timing. |
| Recommendation — Rank remediation by exploitability, exposure and criticality under continuous vulnerability management. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | The article focuses on identifying, tracking and responding to actively exploited vulnerabilities. |
| Recommendation — Apply RA-5 to track exposed flaws and verify remediation before the next exploitation wave. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The Vercel example and exposed control surfaces show how misconfiguration and access exposure enable abuse. |
| Recommendation — Use API and platform hardening to reduce misconfiguration-driven access paths. | ||
Key terms
- Resurgent Vulnerability: A resurgent vulnerability is a flaw that becomes actively dangerous again after the initial disclosure window has passed. The issue is not age alone but persistent exposure, slow remediation and attacker reuse of a known path once defenders have moved on.
- Exposure Window: The period in which a credential, session, or privilege grant can be exploited before it is revoked or expires. Shorter windows help, but they do not solve the deeper question of whether the access remains justified for the full time it is active.
- Platform-Level Aggregation: Platform-level aggregation is the concentration of risk inside a shared service, control plane or hosting layer that can affect many customers at once. A single flaw or compromise can therefore have a broader downstream impact than the same issue on an isolated system.
- Delegated trust: Delegated trust is the decision to let another system or organization issue, validate, or transmit access on your behalf. It is common in cloud and SaaS environments, but it becomes risky when scope, duration, and revocation are not tightly controlled. In NHI governance, delegated trust must be explicit and continuously reviewable.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management. It helps practitioners connect identity controls to the broader security decisions that determine exposure and access risk.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org