To view older blog posts, please visit the archives section.

The Times They Are A-Changin 

How do I write an intro on this subject without sounding like the thousands of other blog posts on this topic? The subject is so pervasive: AI and its impact on the specific threat landscape of vulnerabilities. 

I hesitated before writing this article but I feel my professional experience puts me in a privileged position to be writing it. I was directly involved in both vulnerability research and advanced reverse-engineering, two disciplines that have been historically difficult for humans. As we have come to understand, the times are changing. InfoSec-capable AI models are here and even better ones are on the horizon. While we’ve seen multiple articles on the subject, most writing is commenting on the situation. Little has been published that contains actionable recommendations and insights into how the vulnerability threat landscape could evolve aside from a growth in volume.

This article first frames the current situation and reviews patterns that have been observed in the last 24 months. This is followed by a discussion about the coming impacts both for adversaries and defenders before exploring potential best practices and time frames that defenders could leverage in order to make the most of these changing times.

The luxury of hindsight

CVE publication trends

Everything becomes clear when you have the luxury of hindsight! As many will already be aware, the general CVE publishing trend is upward. Year after year, more vulnerabilities are discovered. But sometimes, the usual trend changes. The Mythos announcement blog post was very clear about one important thing: prior models were absolutely capable of finding vulnerabilities. What they were less able to do was produce a fully working exploit. With this in mind, I decided to turn to the past and see what information could be found in the general CVE publishing patterns. What I found was rather interesting. Below is a graphic depicting the historical CVE publishing trends. “AI periods” are overlaid on top of these.

The graphic shows four periods: pre-frontier LLM era (red), GPT-4 era (yellow), long-context code reasoning era (green), marked by the release of Claude 3, Gemini 1.5, and other frontier systems that made large-context, code-oriented workflows increasingly practical. It ends with what I choose to indicate as the path towards autonomous security research (orange), marked here around May 2025 with the release of Opus 4 and Sonnet 4. 

The hypothesis suggested here is that AI model progression could be one of the explanations for the uptick in the CVE publishing trends observed starting in March 2024. What the graphic shows is an original baseline that was mostly carried from the pre-frontier LLM era into the GPT-4 era. However, around the period when more advanced models became available(Claude 3, March 2024), the trend baseline appears to increase. This goes on for about a year before we start seeing a new trend setting in. This one, more dramatic, starts around May 2025 (Opus 4 and Sonnet 4) and eventually leads us to April 2026 with the announcement of Mythos. While the true causality behind these upticks might never be known, the timeline remains difficult to ignore.

Mythos may have turned the lights on the possibilities of AI in vulnerability research with Mythos, but researchers' adoption of AI possibly started gaining momentum in March 2024. 

KEV publication trends

As I was gathering information for this article, I also turned to CISA’s Known Exploited Vulnerabilities (KEV) addition trends. Excluding the initial inception of the KEV initiative, the last three months are the first to see more than 25 vulnerabilities added to the list in three consecutive months. The previous streak record was two consecutive months above 25 additions, February and March 2025. The following graph shows the historical KEV addition trends. 2026 is represented using orange bars. 

For now, I think we need to be very careful about how we read the KEV data. However, given Anthropic’s claims about Mythos’ exploit development capabilities, KEV additions should be monitored closely, as they always should be, for signs of emerging trends.

A change of seismic proportion

How did we get here?

Vulnerability research is a discipline where a researcher attempts to find vulnerabilities on target systems. Over time, finding significant vulnerabilities has grown increasingly difficult. Long gone are the days where a researcher could find five new vulnerabilities against a serious target in the same day. Through the 2000s, additional security measures were added to most systems that led researchers to turn to different approaches, like fuzzing, and allowed them to continuously find new vulnerabilities. What we are seeing now, with AI, is the continuous adoption of newly available technologies. 

This time however, the shift is slightly different. The use of AI systems opens doors that didn’t even exist before. Where fuzzers help researchers with testing large volumes of inputs, AI systems help them keep track of contextual information in multiple software layers. It allows them to target and zoom into specific code sections. It can increase the capabilities of any active researcher. It also comes with consequences for both defenders and attackers.

Consequences for defenders and attackers

For defenders, the impacts appear easy to grasp: increase in numbers of published CVEs leading to an increase in patches requiring to be deployed. Eventually, it is also probable that the time to exploitation of multiple vulnerabilities will be shorter. There could be an increase in 0-days. 

I think this sums up the initial feelings portrayed by most of the articles I have seen published on the subject. 

However, I would like to suggest that there is likely a lot more to this than what the obvious shows. Attackers are also faced with impacts and challenges from AI technologies. I strongly believe that these impacts should be considered by defenders.

The offensive side of this problem is generally divided into three groups: activists, cybercrime and state actors. For the sake of simplicity I will let activists out of this conversation. For operations that depend on technical exploitation, cybercrime and state-sponsored groups both rely on the availability of exploits. If no exploits are available for their target, three choices are available to them: engage in vulnerability research to find possible 0-days, develop exploits for known vulnerabilities or acquire ready-made exploits available on the market. Before we engage into why this matters, we need to take a step back and evaluate the motivations behind both groups. 

On the cybercrime side of things, theft or ransom is often the end goal. The objective is to make money. Just like any legitimate business, the bottom line is important: less spending equals more profit. This group sometimes even needs their victim to know they’ve been breached: nobody can ask for a ransom without making it known that they were on a given target. Other times, like in theft scenarios, they have a heightened desire to stay private. But they understand that being found out is a possible cost of business and losing offensive capabilities after a cybercrime operation is possible. This is, in essence, an accounting problem.

On the state actors side, things can be very different. Secrecy would be paramount. Getting caught would not only cost money but could lead to attribution. In some contexts, exposure could create diplomatic, operational, and even physical risks. While money is important, no government is in the business of making money.

I suggest to you that cybercrime and state-sponsored actors could be about to go through an interesting period. AI in vulnerability research could lead to a serious disruption in the economics of attackers. This could be transformational in how both groups operate. If the  cost of vulnerability research and exploit development goes down, the financial value of many exploits should also go down. Simple supply and demand case. This also means that the cost of grey market acquisition of exploits could go down. For cybercrime, this is likely, at least initially, a strong business case: more vulnerabilities and exploits equals more business opportunities. The state-sponsored side of things is hard to predict but I would guess that an important increase in the numbers of discovered vulnerabilities could mean potential loss, or compromise, of offensive capabilities on their end. This could happen by a vulnerability being disclosed as a CVE or by a cybercrime actor discovering the vulnerability and getting caught exploiting it. While this would always have been a possibility, a multiplication in the numbers of discovered vulnerabilities certainly heightens the possibility of this happening.

In the end, after a while, and it’s important to not understate the “after a while” part, the real winners in this situation are likely going to be the defenders. Let me explain why.

Case study: Spring

Before diving into this case study, I need to disclose that I reached out to multiple representatives of Spring, Tanzu, and Broadcom for comments on the data presented here. At the time of writing, no response has been received. It is therefore important not to infer confirmed causality from this analysis. The pattern is compelling, but unconfirmed. The data, however, has been extracted and validated by me personally. As we will see later, fully documented cases do exist. However, since the Spring pattern is what initially drew my attention to this question, I have decided to keep this analysis as part of the article.

As we look into Spring and the possible impact of AI vulnerability research on the ecosystem, we first need to understand one important piece of context: Spring is part of Tanzu. Tanzu is a division within Broadcom. Broadcom is listed as being part of the Glasswing project on Anthropic’s website. Glasswing is an invitational initiative where Anthropic allows partners access to the Mythos AI model for defensive security work. This does not, by itself, establish that Mythos was used to identify any Spring-related vulnerability discussed below. However, when combined with the publication and attribution patterns shown in the data, it makes Spring a relevant case study.

Over the last three months, two very interesting trends have emerged in relation to the publication of new vulnerabilities affecting the Spring ecosystem. The first one is the quantity of disclosed vulnerabilities. The following graph shows a worrisome explosion of the number of disclosed vulnerabilities that began in March 2026 and continues to this day (May 2026). The impacted months are highlighted in orange.

This disturbance in the pattern simply can’t be ignored: some years have seen less disclosures than the first half of May 2026 alone. It also got me interested in a simple question: who got credited for these vulnerabilities?

The next thing I did is to have a look at the credits for the most recent vulnerabilities and noticed that a large number of these have not been credited to anyone. So I looked at the complete set of vulnerabilities and extracted the historical patterns shown in the following graph.

The difference for 2026 is once again striking compared to the usual pattern. Zooming in on 2026, we can see that this started in March but really took off in April as shown in the following graph.

By now, you might be wondering: what’s your obsession over the CVE credit pattern? 

To which I will reply: fair question!

What one has to understand about being credited for a vulnerability is that this credit, up to a point, is worth money to a researcher. This credit is important for one’s reputation. Some might not get credited using their real name: many use aliases for privacy reasons. But one way or another, it is customary for researchers to get credited for their discoveries.

To me, such a surge in uncredited CVE disclosure is a strong signal. The uncredited Spring CVEs may be, for now, the visible footprint of Mythos or a Mythos-like workflow.

Based on this, I suggest that Spring could be an early example of what can happen, from a volumetric standpoint, when advanced AI-assisted vulnerability discovery begins to operate effectively against a large software ecosystem.

Now this is all interesting, but in isolation it doesn’t make for a great case study. Let’s compare this data to what has been published in relation to the Curl project’s involvement with Mythos. 

Case study: Curl

On the Curl side, things are slightly different. Daniel Stenberg, Curl’s lead dev, directly published a blog post about their experience with Mythos. 

The AI model found 1 single vulnerability. 

What is the difference between Spring and Curl? Once again, I can’t say 100% sure, however, Daniel’s post about their experience is very interesting. Daniels states that:

“Before this first Mythos report, we had already scanned curl with several different very capable AI
powered tools (I mean in addition to running a number of “normal” static code analyzers all the time,
using the pickiest compiler options and doing fuzzing on it for years etc).”

Curl’s long security history, extensive fuzzing, and continuous use of static analysis may make it a very different target in comparison to a broad ecosystem such as Spring.

Nevertheless I also extracted the CVE disclosure patterns for Curl and it does confirm a different picture even if the volume over the last three months is also higher than usual. This is shown in the following graph.

Case study: Firefox

Once again, a different project, different reality. Frederik Braun at Mozilla also wrote an excellent article about how Firefox has been dealing with Mythos discoveries and how they are harnessing AI to improve their internal processes.

I will not reproduce Frederik graphics here, he has done an excellent job at presenting the volumetric security bug fix data. Let’s simply say that it visually looks very close to what we observed with Spring. In fact, if you look at the numbers, volumetrically it is even more dramatic.

What is very interesting however is Mozilla’s transparency about AI models and how it is affecting their operations. They start by confirming that Mozilla did experiment with AI models from a security standpoint in the past but found the number of false positives to have been too high for this to be a practical and scalable solution. Then, they confirm that the first security reports generated by Mythos were sent their way in February 2026. They were not immediately given access to the model. But, following reception of the Mythos reports, they did start working on harnessing agentic AI to their benefit using Opus 4.6 and found success with it. Once they were given access to Mythos, they replaced Opus 4.6 and used the same harness to leverage Mythos and found even greater success.

The main takeaway for me here is the sequence of actions that were taken:

• Acknowledgement of AI, initial testing, temporary stop or slowdown on the initiative;

• Reception of Mythos reports, recognition of improvements;

• Experimentation and success with Opus 4.6;

• Upgrade from Opus to Mythos.

To this, I feel Mozilla/Firefox represents the most important information point so far. The Mythos reports illustrated and confirmed the operational relevance of AI technologies. Otherwise they would not have resumed their AI related efforts. I think the Firefox case is a statement in how fast a truly mobilized team can turn around and face great challenges.

I believe most businesses will initially be in a similar situation to Spring and Firefox. Curl is unlikely to be the norm. But it certainly is a good example of what can happen when everything goes right even before a seismic event occurs. Based on the data presented so far I think we can move from observation to response. If vulnerability discovery is becoming faster, more scalable, and less predictable, businesses need practical ways to adapt. Let’s look at how these challenges can be faced.

Facing the adversaries

How business will react to this evolution in vulnerability research is important. One thing needs to be understood: this is new ground. Yes there is an increase in volume and yes that will be the most visible part of this new era we’re entering. However, adversaries are also likely to change how they operate. The exact impact on this side is unknown for now. Yes, we can build hypotheses but these are only going to be confirmed much farther down the road. Let’s concentrate on what is known or what we can affirm with a relatively high level of confidence based on experience and history. 

Here are 5 things I think businesses need to properly handle to face this new challenge.

Time

Anthropic’s post (https://red.anthropic.com/2026/mythos-preview/) about Mythos allows us to learn that they believe it will take between 6 to 18 months before other models, or privately owned models, acquire similar capabilities to Mythos. By that point, we should be prepared for the possibility that KEV addition patterns will be affected. Whatever your business does to face this new era, understand that the wave is already here. But you have 6 to 18 months to improve symbiosis between your processes, people and tools before things could become harder. Understand that waiting might not be an option: change and improvement require time. It is very hard to make this happen if your operational teams are too busy responding to waves of vulnerabilities. Assess your strengths and weaknesses. Take this into account when reviewing all other recommendations presented here.

Unity

The various teams forming your IT department need to understand that they are one single team. In most businesses, historical friction exists between teams. This is often true between security teams and development teams. If they are not currently united you need to embark on a PR campaign. Right now. Security people need to understand the competing priorities of development teams. They also need to show other teams that they are doing everything in their power to help them face and prioritize their work. Security teams should make it a point to be transparent. They should also make their work visible as much as possible. When something is required by the security teams, clearly explain the reasons why. If what they are asking is a preventive measure based on the fact that they are not entirely sure about something, also make it transparent. This will help generate conversation, and unity, between teams. When both development and security teams understand each other's challenges, magic, in the form of mobilization, happens. These teams need to be allies.

Landscape knowledge

People climbing Mount Everest hire Sherpas. They do so for many reasons but one of these is for their knowledge and experience of the mountain. They know where the riskiest and safest points are on the way up. Like people climbing a mountain, you need to know the where and what about the most critical services/applications and servers in your infrastructure. Notice I didn’t use the term System. That is on purpose. Systems are composed of multiple services, applications and servers. Knowing what your systems are is great but a given vulnerability might be present at 10 different places within this system. Not all instances of a vulnerability need the same level of attention. Break down the system constructs and evaluate how critical each component of this system is. This evaluation does not need to be complicated. In fact I would venture in saying the simpler it is the better. It will make it easier to evaluate all the components in a standardized approach. This can be done in multiple ways. You need to select a handful of factors that are of importance and relevance to your business and evaluate them. One frequently selected evaluation factor for this is the component exposure to the Internet. In businesses that are highly impacted by PCI, the PCI posture of a component could also be taken into consideration. If you don’t already have this in place, yes you will feel overwhelmed by the task. I invite you to take into consideration how an agentic AI assisted system could help you with this task. Depending on your needs, such an initiative can possibly be built quickly as part of a CI/CD pipeline. Approaching it like this could even remove the burden that data maintenance puts on your teams. In any case, this can’t be ignored. You cannot prioritize vulnerabilities well if you do not know where the vulnerable component lives, how exposed it is, and how critical it is to your business.

Tooling

Tools are required, but don’t fall prey to marketing. You need vulnerability detection tools and a tool that allows you to centralize your data. This is business as usual for a vulnerability management team. The difference is that everything might get faster. The tools should be operationalized in a way that enables your (hopefully) united and aware teams to collaborate on triaging vulnerabilities and shared priorities. For now, as an initial response to a wave of coming vulnerabilities, I would not venture in investing for any specific acquisition past your usual tools. Acquisition processes are long. Solution deployment is long. Solution adoption is also long. Hopefully the tools you have already cover your needs. If you do not have the right tools already in place, focus your internal teams on people and processes. For tooling implementation, consider bringing in professional services from people who have done this before. Let them implement the tools while your own internal teams concentrate on everything else. If this is your case, understand that you are in a precarious position. There simply is no better recommendation here: the right time to prepare tooling was 10 years ago.

People, process and tools (again)

Don’t call me a liar, but we need to talk about tools, again. The team at Mozilla/Firefox turned around and harnessed AI tools to help them find vulnerabilities within a one-to-two months time frame. You should consider the possibility of harnessing AI tools in software patching, testing and release. The pace at which your development teams will have to respond to vulnerabilities is about to increase. In fact if you have been paying attention, you will notice it should have already increased. Development teams will need all the support they can get if they are to be successful at building business value while also patching an unprecedented number of vulnerabilities. Experiment, at least on a small scale, initially with less critical applications, with patching and release automation. This will require coordination within multiple engineering teams that are not usually security centric. Processes are likely going to require adaptation. Possibly complete overhaul. I do believe that this is the big game changer here.

In the end, just like before, your vulnerability management team should be your eyes and observers. They should be your scouts. Development teams need to be able to trust their scouts if they are even going to be willing to fight this fight. Leadership needs to be strong. Hard conversations might be required. In the end, everyone needs the luxury to be able to prepare in an adequate way. This can’t happen without unity.

In front of a new day

I believe we are faced with a new dawn. I hope that AI models and tooling will help us secure a better future. As a community, we shouldn’t be afraid of these new capabilities. We should embrace them. Vulnerability research is inherently neutral. I might be naive but I have to believe that the total number of undiscovered vulnerabilities is finite. Of course new code containing issues will always be written but I have hopes that the surges in CVE publishing could be temporary. How temporary is a billion-dollars question. But if it is temporary, we could eventually see a new baseline set that could very well be lower than what we were historically used to. It might appear like us defenders are losing the battle: the numbers are overwhelming. But never forget that, for every vulnerability that gets discovered, the next one will be harder to find.

On this, I’ll leave you with the wise words of Bob Dylan.

"For the loser now

Will be later to win

For the times they are a-changin"