Project Glasswing: The Day Finding Vulnerabilities Became Easier Than Fixing Them!!

It was essentially this:

We are no longer limited by how quickly we can find vulnerabilities. We are becoming limited by how quickly we can verify, disclose, and fix them.

That is a very different cybersecurity problem.

For years, security teams have complained about not having enough visibility.

We did not know what was vulnerable.

We did not know where it was running.

We did not know which version of a library was being used.

We did not know whether a vulnerability was actually exploitable.

We bought scanners. We deployed SAST. We deployed DAST. We built vulnerability management programs. We created SOCs. We hired penetration testers. We built threat intelligence teams.

The problem was always discovery.

Project Glasswing suggests that this may be changing much faster than many of us expected.

And honestly, I think the next problem is going to be much harder.

What do you do when your machines can find vulnerabilities faster than your engineers can fix them?

Let's start with what Anthropic actually found

Anthropic launched Project Glasswing in April 2026, working with around 50 organizations that maintain software considered important to the internet and wider infrastructure.

The model involved is Claude Mythos Preview, an unreleased model that Anthropic has been testing specifically for cybersecurity capabilities.

In the first month alone, Anthropic says the project helped identify more than 10,000 high- or critical-severity vulnerabilities across partner environments.

Some organizations reported that their vulnerability discovery rate increased by more than ten times.

Cloudflare, for example, reported finding around 2,000 bugs, including approximately 400 high- or critical-severity vulnerabilities, across critical-path systems.

That is a remarkable number.

But the number itself is not what interests me most.

The interesting part is what happens after those 10,000 vulnerabilities are found.

Because finding a vulnerability is only the beginning.

The uncomfortable part starts after discovery

Imagine a security researcher finds a critical vulnerability at 10:00 AM.

Great.

Now what?

Someone needs to reproduce it.

Someone needs to confirm that it is actually a vulnerability.

Someone needs to determine the real severity.

Someone needs to understand which versions are affected.

Someone needs to contact the vendor or maintainer.

Someone needs to write the advisory.

Someone needs to develop a patch.

Someone needs to test the patch.

Someone needs to release it.

Then customers need to install it.

Then security teams need to verify that they actually installed it.

And if the vulnerable software is buried inside another product, the entire chain gets even longer.

That is where the bottleneck moves.

AI can potentially compress the first part of this process from days or weeks into hours, or even less.

The rest of the ecosystem still operates at human speed.

That mismatch worries me more than the vulnerability discovery itself.

The open-source numbers are even more interesting

Anthropic says Mythos Preview has been used to scan more than 1,000 open-source projects.

Across those projects, it identified an estimated:

23,019 vulnerabilities in total

including:

6,202 high- or critical-severity vulnerabilities.

Now, before we get carried away with that number, there is an important caveat.

Not every AI-generated finding is automatically a real vulnerability.

This is exactly why validation matters.

Anthropic says 1,752 of those high- or critical-rated findings have gone through detailed assessment by independent security research firms.

Of those, 90.6% were confirmed as true positives.

And 62.4% were ultimately confirmed as high or critical.

Those are significant numbers.

Even more interesting, Anthropic estimates that the current findings could eventually translate into nearly 3,900 high- or critical-severity vulnerabilities in open-source software after applying the observed validation rates.

And they are still scanning.

That changes the conversation completely.

Here is the part that nobody should underestimate

Open-source maintainers are already under pressure.

Many important projects are maintained by small teams.

Sometimes it is a handful of developers.

Sometimes it is one person.

Yet these projects can sit underneath thousands of companies and millions of applications.

Now imagine that an advanced AI system starts finding vulnerabilities in those projects at a rate that humans have never experienced before.

The AI says:

"Here are 500 vulnerabilities."

The maintainer says:

"Okay. Give me a minute."

Except that "a minute" might actually mean weeks.

Anthropic says some maintainers have even asked them to slow down their disclosures because they simply don't have enough capacity to process the findings.

That is an incredibly important detail.

Because it tells us something we often miss when talking about AI-powered security.

Discovery capacity and remediation capacity are two completely different things.

We are very good at talking about increasing the first.

We don't talk nearly enough about increasing the second.

AI could create a vulnerability backlog we cannot handle

Think about a normal enterprise.

You might already have:

• Thousands of servers
• Hundreds of applications
• Thousands of containers
• Tens of thousands of dependencies
• Hundreds of APIs
• Multiple cloud environments
• Legacy applications
• SaaS platforms
• Kubernetes clusters
• Internet-facing services

Now introduce an AI system that continuously reviews your code and infrastructure.

You might go from:

"We don't know what is vulnerable."

to:

"We know exactly what is vulnerable, and there are 40,000 things to fix."

That sounds like progress.

But operationally, it can become a nightmare.

Your security team is suddenly generating findings faster than engineering can consume them.

Developers start receiving security tickets faster than they can work on them.

The vulnerability backlog gets larger.

People start ignoring alerts.

Critical findings get buried among less important findings.

And eventually someone says:

"Can we just turn the scanner off for a while?"

We have seen versions of this problem before.

The difference is that AI could dramatically increase the scale.

This is why vulnerability counts are becoming less useful

I have never been a big fan of judging security maturity by the number of vulnerabilities an organization has.

A dashboard showing:

12,438 vulnerabilities

doesn't tell me much.

What I want to know is:

How many are actually exploitable?

How many are internet-facing?

How many are reachable?

How many affect critical applications?

How many involve privileged components?

How many have public exploits?

How many have compensating controls?

How many can actually lead an attacker to something important?

That is the difference between vulnerability management and exposure management.

And AI makes that distinction even more important.

A CVSS 9.8 vulnerability isn't automatically your biggest problem

Let's say you have two vulnerabilities.

The first has a CVSS score of 9.8.

It exists in a library somewhere inside an internal application.

The application is not exposed to the internet.

The vulnerable functionality isn't used.

The system is heavily segmented.

The application has very limited privileges.

You probably still want to fix it.

But now consider another vulnerability with a CVSS score of 7.5.

It affects an internet-facing API.

It requires no authentication.

The service runs with elevated privileges.

It connects directly to your identity infrastructure.

And it has access to sensitive customer data.

Which one worries you more?

Probably the second one.

This is why I expect AI-driven security programs to move away from simply asking:

"How severe is the vulnerability?"

and toward:

"Can an attacker realistically use this vulnerability to get somewhere important?"

That is a much better question.

The wolfSSL example is worth paying attention to

One of the examples Anthropic disclosed involved wolfSSL, an open-source cryptographic library used by billions of devices.

Mythos Preview reportedly constructed an exploit that could allow certificate forgery.

Think about what that means.

Certificates are one of those things most people never think about.

Your browser connects to a website.

You see the padlock.

You assume you are talking to the real website.

Cryptography is supposed to make that trust possible.

A vulnerability that allows certificate forgery can attack that trust relationship directly.

Anthropic says the vulnerability has been patched and was assigned CVE-2026–5194.

The full technical analysis is expected later, after sufficient patch deployment.

This is a good example of why AI vulnerability research is not just about finding more bugs.

It is about finding weaknesses in assumptions that the rest of the security ecosystem depends on.

The really interesting shift is from scanning to reasoning

Traditional security scanners are very good at certain things.

They can tell you:

"This package is vulnerable."

Or:

"This configuration is insecure."

Or:

"This endpoint appears to be exposed."

Useful.

But an advanced AI system can potentially ask a much more interesting question:

"If I were an attacker, how could I use this weakness?"

That is different.

A real attack rarely depends on a single vulnerability.

It might look something like:

Internet-facing application ↓ Application vulnerability ↓ Initial access ↓ Credential discovery ↓ Privilege escalation ↓ Access to internal service ↓ Identity compromise ↓ Sensitive data

That is an attack path.

And this is where AI becomes particularly interesting.

The value is not necessarily finding 10,000 individual vulnerabilities.

The value could be finding the five vulnerabilities that create the most dangerous attack paths.

This is where penetration testing could change dramatically

Think about how a traditional penetration test works.

You hire a team.

They spend time learning the environment.

They enumerate assets.

They identify vulnerabilities.

They test them.

They build attack paths.

They write a report.

It can take weeks.

Now imagine having an AI security agent doing a similar process continuously.

Not once a year.

Not once every six months.

Every day.

The agent could continuously ask:

What changed?

What new services appeared?

What vulnerabilities were introduced?

What new attack paths exist?

What changed in identity permissions?

What new internet-facing assets appeared?

Can I reach a critical system from the internet?

That starts to look less like traditional penetration testing and more like continuous adversarial validation.

I think that is where this technology becomes particularly interesting.

But there is a catch

We should not assume that giving an AI access to your environment is automatically a good idea.

It isn't.

A highly capable security agent is itself a powerful system.

Give it too much access and you have created another potential security problem.

Imagine an AI agent with:

• Source code access
• Cloud credentials
• Production access
• Kubernetes permissions
• Security tooling
• SIEM access
• Identity administration
• Ability to execute commands

That agent could be incredibly useful.

It could also become incredibly dangerous if compromised, manipulated, or misconfigured.

So the security architecture around AI agents matters.

A lot.

I would treat AI agents like privileged users

Every AI security agent should have its own identity.

It should have narrowly defined permissions.

Its actions should be logged.

Its tools should be restricted.

High-impact actions should require approval.

Production changes should have clear controls.

Secrets should not simply be handed to the model.

And there should be a way to shut the agent down immediately.

In other words:

Don't give your AI security agent the keys to the building just because it promises to improve security.

Security teams should apply the same principles to AI agents that we already apply to privileged human identities.

Least privilege.

Segmentation.

Monitoring.

Strong authentication.

Auditability.

Controlled elevation.

There is another problem: AI-generated security noise

Anthropic mentions something that I think deserves much more attention.

Open-source maintainers are already receiving a flood of low-quality AI-generated vulnerability reports.

This is going to become a problem.

If anyone can ask an AI:

"Find vulnerabilities in this project."

and immediately send the output to a maintainer, the result could be thousands of poorly validated reports.

That doesn't improve security.

It creates work.

And eventually maintainers may start ignoring reports.

That would be a terrible outcome.

So if we are going to use AI for vulnerability research, we need to take responsibility for validating the findings.

Don't just send:

"AI says this is CVSS 9.8."

Show the evidence.

Reproduce it.

Explain the impact.

Identify the affected versions.

Provide useful remediation information.

Make the maintainer's job easier, not harder.

The future may be automated remediation

This is the part that excites me the most.

Finding vulnerabilities is only half the problem.

What if the same AI that discovers the vulnerability could also prepare the fix?

Imagine this:

A vulnerability is detected.

The AI identifies the affected dependency.

It finds the safest patched version.

It updates the dependency.

It runs the test suite.

It runs security tests.

It checks for breaking changes.

It creates a pull request.

The developer reviews it.

The pull request gets merged.

The pipeline deploys it.

The AI then checks production and confirms that the vulnerable version is gone.

That is a completely different security operating model.

The goal isn't:

"AI found 10,000 vulnerabilities."

The goal becomes:

"AI found 10,000 vulnerabilities and helped us safely eliminate 9,500 of them."

That is where the real value is.

Security teams need to measure the whole pipeline

I think we will eventually need a different set of metrics.

Not just:

How many vulnerabilities did we find?

But:

How quickly did we find them?

How quickly did we validate them?

How quickly did we prioritize them?

How quickly did engineering fix them?

How quickly did the fix reach production?

How quickly did we verify the fix?

And perhaps most importantly:

How much exploitable exposure remains?

That last number is the one I care about.

AI could make patch management a competitive advantage

Patch management has traditionally been treated as operational hygiene.

Something IT has to do.

I think that is going to change.

If attackers can discover vulnerabilities extremely quickly, then the organizations that can patch extremely quickly will have a genuine security advantage.

Two companies might have exactly the same vulnerability.

Company A takes 45 days to deploy the fix.

Company B deploys it within hours.

They have the same vulnerability.

They don't have the same risk.

The difference is operational maturity.

What should security teams actually do today?

I don't think the answer is to immediately deploy an autonomous AI hacker into production.

There are more sensible starting points.

Start with your own code.

Let AI review repositories.

Ask it to identify security issues.

Have it explain why they matter.

Validate the findings.

Then ask it to propose fixes.

Keep humans involved.

Measure how much time it saves.

Then gradually expand.

You can apply the same approach to:

• Threat modeling
• Secure code review
• Dependency analysis
• Penetration testing
• Detection engineering
• Threat hunting
• Incident investigation
• Attack-path analysis
• Security regression testing

The important part is not to chase the most impressive AI demo.

The important part is to identify where AI can remove friction from your existing security process.

The CISO question I would ask

If I were sitting with a security leadership team today, I would not ask:

"Do we have an AI security strategy?"

That question is too broad.

I would ask:

"If an AI discovered a critical vulnerability in our environment tonight, how long would it take us to identify every affected asset, determine our actual exposure, deploy a fix, and prove that we are no longer vulnerable?"

Then measure it.

If the answer is:

30 days

that is a problem.

If the answer is:

7 days

better.

If the answer is:

24 hours

you are getting somewhere.

If the answer is:

minutes, with appropriate human approval

then you are operating in a very different security model.

We are entering an interesting period

There is a strange irony here.

For a long time, security professionals wanted better tools to find vulnerabilities.

Now we may be entering a period where the tools are becoming better at finding vulnerabilities than organizations are at fixing them.

That sounds like a good problem to have.

It isn't necessarily.

If the discovery engine becomes ten times faster but remediation remains exactly the same, the gap between discovery and remediation simply gets larger.

And attackers don't need thousands of vulnerabilities.

They need one useful one.

That is why I think the next major cybersecurity race will not simply be about who has the best vulnerability discovery model.

It will be about who can build the fastest secure remediation loop.

My biggest takeaway from Project Glasswing

Project Glasswing is not just another story about AI finding vulnerabilities.

It is a warning about where the bottleneck is moving.

The old problem was:

We can't find vulnerabilities fast enough.

The new problem may become:

We can't fix vulnerabilities fast enough.

And eventually, if AI becomes capable of finding and exploiting vulnerabilities at very low cost, the question becomes even more serious:

Can defenders reduce exposure faster than attackers can discover useful paths into the environment?

That is the race I would be watching.

Not AI versus humans.

Not ChatGPT versus hackers.

Something much more practical.

Machine-speed discovery versus human-speed remediation.

The organizations that figure out how to close that gap are going to be in a much stronger position.

And perhaps the most important lesson from Project Glasswing is this:

The future of vulnerability management isn't finding more vulnerabilities.

It is fixing the right ones, quickly, safely, and continuously.

That is where the real battle begins.

A personal note !!

The figures and examples in this article come from Anthropic's public Project Glasswing update. Anthropic reports that approximately 50 partners collectively identified more than 10,000 high- or critical-severity vulnerabilities, while its open-source scanning effort identified an estimated 6,202 high- or critical-severity vulnerabilities across more than 1,000 projects. These figures are Anthropic's reported results and should be understood in that context.

Project Glasswing: An initial update An early update on what we've learned from Project Glasswing.

What Is Project Glasswing? How Anthropic Is Using Claude Mythos to Secure the Internet Project Glasswing is Anthropic's coalition with AWS, Google, and Microsoft to harden software using Claude Mythos…