The question is not "will they find it", but "when will you fix it"

Spring 2026 made security conversations loud again. On 7 April Anthropic announced Project Glasswing and said its Claude Mythos Preview model had already found "thousands of high-severity vulnerabilities", including some in every major operating system and web browser. The company does not plan to release the model generally. That is a vendor claim, not an independent assessment, and it should be read as one.

The UK AI Security Institute (AISI) gives a more independent view. In its evaluation of 13 April, AISI reports that the model was the first to complete "The Last Ones", a 32-step range simulating an attack on a corporate network, from start to finish, but in only three of ten attempts. AISI itself adds a caveat: the range has no active defenders or defensive tooling, so it cannot say how the model would fare against well-defended systems.

The practical question applies to any organisation. If vulnerabilities are found faster, the winner is not whoever scans the most, but whoever closes what is found the fastest. So ask yourself: how many days do you have between "found" and "fixed"?

No panic: what the data says

The data does not support an "AI will break everything" tone. Mandiant's M-Trends 2026 states plainly that 2025 was not the year in which breaches were the direct result of AI, and that the vast majority of successful intrusions still stem from fundamental human and systemic failures. The sober conclusion is that basics matter more than novelty.

The same report also shows why the basics have to be done quickly:

• exploits were the initial infection vector in 32% of intrusions, first place for the sixth year running, and voice phishing rose to 11%;

• Mandiant estimates the mean time to exploit at minus seven days, meaning attacks often begin before a patch exists;

• the hand-off from one threat group to another fell from more than eight hours in 2022 to 22 seconds in 2025.

VulnCheck's State of Exploitation 2026 adds that 28.96% of vulnerabilities added to the KEV list (Known Exploited Vulnerabilities, those with evidence of real-world exploitation) in 2025 were exploited on or before the day their CVE was published. The most frequently targeted technologies were network edge devices: firewalls, VPNs and proxies.

How many days do you actually have

Now consider how organisations are coping. According to the Verizon 2026 DBIR, which draws on data from more than 13,000 organisations, only 26% of vulnerabilities in the CISA KEV catalogue were fully remediated in 2025, down from 38% the year before. The median time to full remediation rose to 43 days from 32. In the same report, exploitation of vulnerabilities is the most common initial access vector.

Set that against the previous section. Some attacks start before the patch, others on the day of disclosure, while the DBIR median for full remediation is 43 days. The gap lies there, not in the fact that someone found one more flaw.

Five steps that shrink the gap

1. Prioritise by evidence of exploitation, not only by CVSS. A CVSS score (Common Vulnerability Scoring System, a severity rating) describes potential danger. CISA's KEV catalogue tells you a flaw is already being used in attacks. If a KEV-listed vulnerability sits on your perimeter, it goes to the front of the queue, even with a middling score. Build it into your prioritisation rule: "listed in KEV" moves a ticket up automatically.

2. Set a separate deadline for critical items. A general "we patch on schedule" fails when exploitation begins within days. Write a distinct, short deadline into your policy for KEV-listed vulnerabilities and for anything on the perimeter, and decide who may take a service down to apply an update. The deadline should be one you can genuinely meet: an unreachable number on paper is worse than an honest one.

3. Verify the fix worked. "Patch installed" does not mean "vulnerability closed". The update may not have reached some servers, a service may not have restarted, a configuration may keep the old path open. It is no accident that the DBIR counts "fully remediated" and "partially remediated" separately. After every fix to a critical vulnerability, rescan and record the result.

4. Scan the perimeter continuously. Your external perimeter changes faster than you inventory it: new subdomains, forgotten test environments, devices after a firmware update. A quarterly scan shows the state on a single day. Regular vulnerability scanning with an automatic comparison of what is new shortens the time between a problem appearing and you knowing about it. A penetration test then shows what a scanner cannot: how several small weaknesses combine into a real attack path.

5. Review code before release. The cheapest vulnerability is the one that never reaches production. If you write your own software, a secure code review before release removes a whole class of problems that would otherwise have to be patched in a hurry. This matters most for services exposed to the internet.

Where to start this month

Not with a new tool. Pick one metric: how many days pass between a vulnerability being detected and its confirmed closure. Calculate the median separately for KEV-listed items and for the rest. Then look at the oldest open items on your perimeter, because that is usually where the story told by this year's reports is hiding.

If the number surprises you, that is normal. What matters is that it stops being unknown. After that it is an engineering task: an owner for each system, a deadline, a re-check.

Would you like to look at your own gap between "found" and "fixed" with us? Let's talk.