How does the 24-hour exploitation window affect patch management?

Mandiant's 2026 threat intelligence data shows 28.3% of disclosed CVEs are exploited within 24 hours of public disclosure, before most organisations complete even an initial risk assessment, let alone patch. This compresses the window between a vulnerability becoming public knowledge and active exploitation to a period where traditional patch management processes cannot respond in time. Compensating controls and network-level mitigations have become the primary immediate defence.

What defensive steps should security teams prioritise given AI-accelerated exploitation?

Security teams should focus on three areas: building network-layer compensating controls that can be deployed faster than patches (WAF rules, firewall blocks, load balancer config changes); establishing a triage process for high-severity CVEs that triggers within hours of disclosure rather than days; and using attack surface management tooling to identify which disclosed vulnerabilities exist in their specific environment, filtering out the noise.

Project Glasswing and the AI Vulnerability Race No One Is Winning

Q: What was Project Glasswing and what did it find?

Project Glasswing was an AI-assisted vulnerability research programme that identified over 10,000 critical vulnerabilities across production software in approximately one month of automated analysis. The programme combined fuzzing, static analysis, and LLM-guided code review to surface flaws that traditional manual and automated tools had missed, demonstrating that AI can scale vulnerability discovery well beyond what human researchers alone can achieve.

10,000 critical vulnerabilities. One month. That’s what Project Glasswing found in production software using automated AI-assisted analysis. For context: the entire CVE database grew by roughly 28,000 entries across all of 2023. Glasswing matched a third of that in thirty days, covering a slice of the codebase, not everything.

The headline reads like a defender win. More vulnerabilities found means more vulnerabilities patched. Except the same tools that found them can find them for someone else. And the people on the other side don’t have to fix anything; they just have to build the exploit first.

What Glasswing actually did

The programme combined fuzzing, static analysis, and LLM-guided code review; but the specific contribution wasn’t the combination, it was the seed generation for fuzzing.

Modern fuzzers are technically capable and practically limited. They generate coverage in shallow code paths because random and mutation-based inputs can’t reach the logic conditions guarding deeper functionality. You can run a well-configured fuzzer against a parser for weeks and never hit the edge case that matters because the edge case requires understanding what the parser expects, not just throwing bytes at it.

The LLM component addressed this directly. Instead of random or mutated inputs, it generated semantically meaningful payloads: structured data that looks like legitimate input, edge cases reflecting actual protocol constraints, sequences designed to exercise state machines in non-obvious orders. The result was meaningful coverage improvement in exactly the places where vulnerabilities concentrate: input validation boundaries, parser edge cases, state transition logic, deserialization paths.

That’s not a marginal improvement. That’s why the discovery numbers look like they do.

28.3% exploited within 24 hours

Glasswing’s find rate is striking. The Mandiant number is the one that changes how you operate.

In Q1 2026, 28.3% of disclosed CVEs were exploited within 24 hours of public disclosure. Not eventually. Within one day.

Walk through what 24 hours actually means for an enterprise security team receiving a high-severity advisory: verify the vulnerability affects your environment, confirm blast radius, locate affected systems in inventory, assess whether a patch exists and is tested, schedule a change window, deploy. That process takes days under normal conditions. The organisations running leaner (which is most of them, with the staffing situation being what it is) take longer, not shorter.

A quarter of critical CVEs now see active exploitation before most security teams have finished reading the advisory. That’s not a resourcing gap. No amount of headcount solves a 24-hour window under conventional patch management processes. It’s a structural mismatch between the speed of exploitation and the speed of institutional response.

Why it accelerated

Weaponisation timelines have been trending faster for years, but the AI inflection is real. Certain steps that required skilled manual work are now largely automatable.

Patch diffing is the clearest case. When a vendor ships a security update, the diff between patched and unpatched binaries shows the change. Experienced vulnerability researchers have always been able to read a diff and work backwards to the vulnerability. LLM-assisted analysis does much of this mechanically: identify the modified code, classify the change type, hypothesise what conditions trigger the flaw, generate test cases. What used to require a skilled reverse engineer with days of time is now significantly faster.

The CVE advisory itself is sufficient to direct automated analysis. Affected component, vulnerability class, version ranges: that’s enough starting information to generate a proof-of-concept. Measured in hours, increasingly, not days.

The same dynamic applies to fuzzing campaign setup, exploit primitive identification, and shellcode generation. These aren’t solved problems but they’re substantially easier than they were three years ago.

The defender advantage is real but conditional

Glasswing-style programmes do create genuine defender advantages. A vendor running automated analysis against their own codebase has access to source, build systems, and test environments that attackers don’t. The asymmetry matters.

The complication is that binary analysis doesn’t require source access and it’s gotten faster. Attackers with equivalent tooling can run the same analysis against widely deployed software. They don’t need to fix what they find.

More AI-assisted vulnerability research accelerates both discovery-and-patch for defenders and discovery-and-exploit for attackers. Which side benefits more from the acceleration depends on who has better tooling, more resources, and faster operational tempo. The 2025–2026 evidence doesn’t clearly resolve in favour of defenders. It’s more honest to say the question is open.

What security operations actually needs to change

Patch management as a primary control isn’t wrong; patches should be applied. But a control operating on week-to-month timelines can’t be the first line of defence against threats operating on hour-to-day timelines. That’s just arithmetic.

The controls that remain viable in this environment share one property: they deploy faster than patches.

Network-layer mitigation first: WAF rules, firewall ACL changes, load balancer configuration, network segmentation. Going from advisory to deployment in hours is achievable with these. Virtual patching via WAF is imperfect and can be bypassed. It closes the obvious attack paths while proper patching is under way. That’s worth doing.

Attack surface visibility is no longer optional: most disclosed CVEs won’t be exploited against most organisations. The 28.3% figure covers the entire CVE universe; the subset relevant to any particular environment is smaller. But you have to know which subset that is. Attack surface management tooling that can answer “does this CVE affect us and where” has moved from useful to load-bearing.

Same-day triage for high-severity disclosures: a Monday morning advisory should trigger same-day assessment, not the next vulnerability management meeting. The organisational process needs to match the threat timeline. For most teams, that requires pre-defining what triggers an urgent response and who owns it, not ad-hoc escalation.

There’s no clean technical fix for the underlying dynamic. AI-assisted tooling has compressed exploitation timelines past the point where conventional patch management closes the gap, and the same tooling is available to attackers. What exists is a set of controls (faster detection, network-layer mitigation, attack surface visibility, process velocity) that reduce exposure in the window patch management can’t cover.

Glasswing demonstrated the capability. The capability doesn’t stay on one side of the line. The organisations who’ve updated their threat model accordingly are operating with more accurate assumptions than the ones still running patch management on a weekly cadence and calling it a vulnerability programme.

References

Mandiant M-Trends 2026: exploitation timeline data and threat intelligence: https://www.mandiant.com/resources/m-trends
MITRE ATLAS: AI-assisted attack techniques and automated vulnerability discovery: https://atlas.mitre.org/
NIST AI RMF: guidance on AI-assisted security tooling and adversarial risk management: https://airc.nist.gov/
OWASP: vulnerability management and patching guidance for security teams: https://owasp.org/