Two announcements about frontier AI models focused on cybersecurity, Claude Mythos and OpenAI GPT-5.4-Cyber, have generated a tsunami of press and speculation about the future of vulnerability exploitation. Much of the discussion has been alarmist, suggesting that attackers will be able to use these models to compromise any operating system or browser in the market, while other analysts have called into question the accuracy of the early press.
Regardless, AI is improving at automating vulnerability and exploit research. While much of what we know about these two models is from marketing material rather than real-world usage by researchers, it’s not unreasonable to extrapolate that advances in these platforms will stress developers, particularly in the open source arena, and defenders tasked with protecting organizations against compromise.
Claude Mythos (Anthropic Mythos AI model) is Anthropic's newest frontier model. Anthropic reports that, in testing, it autonomously found thousands of zero-day vulnerabilities across every major operating system and web browser, including a 27-year-old bug in OpenBSD and a 16-year-old remote code execution flaw in FreeBSD, without human direction. Anthropic engineers with no formal security training could prompt Mythos to find remote code execution vulnerabilities, go to sleep, and wake up to a complete, working exploit.
Anthropic decided not to release Mythos publicly yet. Instead, it launched Project Glasswing, a controlled consortium of roughly 40 organizations including Apple, Google, Microsoft, and Amazon, providing early defensive access backed by $100 million in usage credits.
Researchers have raised questions about the capabilities of Mythos; for example, Firefox exploit code described by Anthropic didn’t actually work in Firefox. Instead, it was executed in a limited test environment without any of Firefox’s defense-in-depth controls that would’ve prevented the exploits from working.
OpenAI followed within days. GPT-5.4-Cyber, part of the broader GPT-5.4 model family, is a variant of GPT-5.4 fine-tuned for defensive security work. It carries fewer restrictions on vulnerability research, exploit analysis, and binary reverse engineering, and is rolling out through a tiered Trusted Access for Cyber program to thousands of vetted security professionals. OpenAI's complementary Codex Security tool has already contributed to fixes on more than 3,000 critical and high-severity vulnerabilities across open source projects.
Two companies, two different bets on how broadly to release these capabilities.
It is indisputable that the number of vulnerabilities in the software ecosystem is increasing and that, for vulnerabilities that are exploited in the wild, the window between disclosure and exploitation is shrinking. Both of these trends existed before AI tooling began augmenting vulnerability research and the widespread adoption of new models promises to extend the trends.
On the other hand, research shows that organizations typically are able to patch about 10% of all vulnerabilities that are open in their environment regardless of size. In my experience, almost all organizations are already struggling with vulnerability management – I can’t recall the last time that I talked to a cybersecurity leader who was satisfied with their program – and increases in the number of vulnerabilities and exploits obviously doesn’t help.
Ultimately, while AI may be increasing pressure on defenders, it’s important to note that this is an acceleration of existing techniques. While many pundits are repeating that you need AI to protect against AI, there’s no evidence that this is true in vulnerability management; in fact, the same things that protect against determined human adversaries are also going to protect against adversaries leveraging AI-driven vulnerabilities and exploits.
The first answer is that organizations need to ruthlessly prioritize where & when to patch. If you can only reasonably patch 10% of open vulnerabilities, it’s important to target the right 10%. There are some key approaches to this that have arisen in the last several years and organizations should be thinking about how to embrace them to focus efforts.
This is where most vulnerability management programs start. By definition, a critical CVE is riskier than a high severity one…and medium and low severity CVEs are even less risky. Most programs focus primarily on criticals & highs first.
This has become somewhat more complicated as responsibility for scoring CVEs has shifted from NVD to the organizations filing CVE reports (CVE Numbering Authorities, or CNAs). CVSS scoring has proven to be somewhat subjective and research shows that different researchers will, sometimes, assign different (even radically different) scores to the same vulnerability.
Obviously, we can’t rely solely on severity to make decisions. Another powerful approach is to prioritize vulnerabilities that are known to be exploited or that are likely to be exploited.
Known Exploited Vulnerabilities, or KEVs, are lists of CVEs that have been observed being exploited in the wild. The primary source of this intelligence is the CISA KEV list, maintained by the US Cybersecurity & Infrastructure Security Agency, or CISA. CISA KEV is somewhat limited in that it focuses on the software that the US Federal Government and critical US infrastructure uses – other organizations such as VulnCheck maintain broader lists of KEVs.
Prioritizing vulnerabilities that are known to be exploited is important but, given the shrinking window between disclosure and exploitation, it’s probably not enough. The Exploit Prediction Scoring System (EPSS) provides an estimation of the likelihood that a CVE will be exploited in the next thirty days. This provides an additional layer of prioritization intelligence that allows organizations to prioritize for the potential of exploitation.
Simply speaking, exposure is a determination of whether an endpoint is available via the Internet. Not all vulnerability risk comes from exposed systems but exposed systems are at higher risk – a system that is not externally reachable can only be exploited by a malicious insider or by an attacker who has already gained access to the internal network.
If exposure tells us whether an external actor can get to the endpoint, reachability is a newer measure that tells us whether you can get from the endpoint to the code that is actually vulnerable. Broadly, there are two types of reachability analysis available in modern security tools.
The first type, which I’ve been referring to as static reachability, uses code & dependency analysis to determine whether it is possible to reach the vulnerability – are there code paths that could reach the vulnerability? This sort of analysis is commonly found in developer-focused tooling and is useful in development and CI/CD environments.
The second sort of reachability, “dynamic reachability” in my head, uses runtime monitoring to see if the vulnerable components and code paths are actually used. This requires a runtime agent. Dynamic reachability has higher fidelity (as it shows actual usage rather than potential) but may also miss uncommon code paths that an attacker may be able to trigger.
An additional factor in prioritization is, simply, how important is this asset? Organizations should be far more concerned about critical systems than they are about others; however, it’s important to include attack path analysis in this analysis – some systems may not be crown jewels but they may have connectivity to higher value assets.
Another primary defense is attack surface reduction. In vulnerability management, this is manifesting as a reduction in the amount of code present on systems at all – this is the primary mission of Minimus and, unsurprisingly, I am a big fan of this approach.
As a practical example, a developer building a Python container using the latest public container from Docker Hub gets an image with 472 OS packages in it before they add any of their own code & dependencies – this includes 314 known CVEs with 9 of this being rated as critical. These packages include things that are needed to run a Python application, like Python, but it also includes hundreds of others that aren’t needed to meet the developer’s goals.
Minimus’s Python image has 23 OS packages in it – only what’s needed to accomplish the mission. This reduces the number of known CVEs, as of today, to 2 medium severity vulnerabilities.
Going back to the 10% number cited above…10% isn’t a law of physics; rather, it is the cumulative weight of all of the CVEs that an organization is seeing and the friction of addressing them all. Empirically speaking, organizations that have less noise in their vulnerability management program are better able to address the vulnerabilities that remain.
This reduction in components also makes it harder for attackers to live off the land if they do find an exploit – without a shell, without cURL or wget, without other components that the application doesn’t need, the bar is far higher for the attacker to gain persistence, perform recon, move laterally, and exfiltrate data.
When I was an incident response leader, I often talked about the Defender’s Paradox – as a defender, I have to be right all the time but an attacker only has to be right once. Ten years ago, this was broadly true; however, times have changed.
Zero-trust approaches are segmenting organizations into bulkheads and they fundamentally shift us away from the Defender’s Paradox. These approaches force attackers to work harder for every lateral movement in an incident and give defenders time to detect, contain, and respond. Cloudflare’s Thanksgiving incident is a great illustration – their embrace of zero-trust enabled them to contain a talented attacker to a very small part of their enterprise.
Full zero-trust is a daunting task. Organizations should be thinking about what they can do to move towards better segmentation even if a full implementation isn’t immediately possible.
In the face of so much angst, defenders need to focus on effective protections and defense-in-depth rather than giving in to despair. Even as new approaches enable attackers, the fundamentals of defense remain unchanged.
As AI accelerates vulnerability discovery, the shift from reactive patching to proactive risk reduction is more important than ever. Minimus provides teams with minimal, hardened Instead of chasing down thousands of AI-generated findings, Minimus base images reduce vulnerability volume at the source, without changing how your team builds or ships software. Get a demo to see how it works.
.svg)
.svg)
.svg)
.svg)
