Notifications
Clear all
Topic starter
18/08/2026 2:17 pm
TL;DR: AI-assisted attackers now turn disclosed vulnerabilities into working exploits before many enterprises can remediate them, with J.P. Morgan citing near-82% of exploitations on or before disclosure day and a 12-hour median time to exploitation. Apiiro's article argues that patch cycles built for human-paced threats are being overtaken by machine-speed discovery and exploitation.
NHIMG editorial — based on content published by Apiiro: Patchmageddon and the race to patch before AI exploits proliferate
By the numbers:
- According to J.P. Morgan's cited analysis from Sidero Labs, attacker time-to-exploit crossed organization time-to-remediate around 2025, meaning attackers now begin exploiting before a patch is publicly available.
- The share of exploitations occurring on or before the day of disclosure has climbed to nearly 82%, according to the Zero Day Clock.
- Median time-to-exploitation has fallen to 12 hours, according to the Zero Day Clock.
Questions worth separating out
Q: How should teams prioritise patching when exploitability assumptions are no longer stable?
A: Prioritise by exposure, privilege, and business reach, not only by exploitability score.
Q: Why do AI-enabled attacks change the value of traditional vulnerability management?
A: They reduce attacker cost and speed up reconnaissance, phishing, and exploitation, which means the defender’s old timeline no longer fits the threat.
Q: What do teams get wrong about patch compliance?
A: They often confuse documented patch policy with actual risk reduction.
Practitioner guidance
- Rebuild remediation SLAs around exploitability, not calendar targets Set escalation thresholds based on reachability, exposure paths, and known active exploitation, then route only truly reachable assets into the highest-priority queue.
- Tie CI/CD and deployment privileges to emergency patch authority Map which service accounts, pipeline tokens, and deploy credentials can actually push a fix, then separate emergency repair access from everyday build access.
- Use software graphs to identify reachable exposure first Prioritise remediation using dependency and runtime context so scanners do not drive false urgency.
What's in the full article
Apiiro's full article covers the operational detail this post intentionally leaves for the source:
- How Guardian Agent uses the AppSec Data Fabric to map software architecture to business risk
- How the Software Graph and Risk Graph identify which vulnerable instances are actually reachable
- How AutoFix packages, tests, and prepares a safe pull request before human review
- How open source maintainers are being supported with free root-cause AutoFix to reduce upstream lag
👉 Read Apiiro's analysis of Patchmageddon and AI-driven exploit speed →
Patch windows are collapsing fast, are your remediation controls keeping up?
Explore further
18/08/2026 3:10 pm
AI has turned patch management into a governance race, not a maintenance task. When attackers can reverse-engineer patches and produce weaponised exploits faster than a change ticket can move, the question is no longer whether teams have a patch process. The question is whether that process is fast enough to matter against a machine-speed adversary. Practitioners should therefore treat remediation latency as a board-level exposure metric, not an operational afterthought.
A question worth separating out:
Q: Who is accountable when compromised access infrastructure keeps working after patching?
A: Accountability sits across platform owners, IAM teams, and security operations because patching alone does not remove persistence or confirm that access state has been cleaned up. Frameworks that matter here include least-privilege and configuration management controls, plus the operational responsibility to verify that no unauthorized access path survives remediation.
👉 Read our full editorial: Patchmageddon shows patch windows collapsing under AI-driven exploits
