New serious vulnerabilities spiked around release of Claude Mythos Preview
epoch.ai
epoch.ai
In other words, a weapons missle defense system is equivalent to an attack one.
I think that applying this thinking to software is a mistake. A lot of commercial software uses open source libraries under the hood, and and while the large corporations might have access to Mythos/Fable/gpt 5.6, the open source library maintainers typically don’t. That leaves them vulnerable to foreign adversaries who do have access to AI models. Attackers don’t need Mythos-level capability then, they just need to outperform whatever the maintainers are using.
Which means that Anthropic’s decision to restrict security research on even Sonnet makes that gap (and thus an attackers opportunity) even larger.
I say this as a coder who wants to release some of my internal libraries to open source. The risk now is that I open up my own products (which use those libraries) to vulnerability scanners while not having those kinds of detection methods myself. This, it’s safer to not release and keep internal than to risk increasing my own attack risk.
Hopefully we will come to see that software is not equivalent to missle defense — writing safe code is different than attacking others’.
So I suspect this has less to do with the underlying ethics or logic, and more to do with Anthropic not wanting to be held responsible for unleashing a potential period of chaos onto the world.
Of course, if someone has access to a tool that can find vulnerabilities in code, the process is identical whether the ultimate intent is to fix or exploit them (which may be Hegseth's underlying logic?). So to avoid this 'world chaos' scenario, Anthropic needs to somehow restrict Mythos access, avoiding bad players. And the only heuristics available at scale are either task-based assessment by AI (with downgrading of anything marginally risky to older models) or selection of trusted organisations by humans.
(By the by, to your point, it would also make sense to expand Glasswing to open source maintainers, at scale. I can't tell to what extent this has been part of that project?)
Seems like there is a fair chance that it will mostly be an actual spike, where's a bunch of existing vulnerabilities get cleaned up and then published software mostly has less vulnerabilities going forward.
FLOSS projects keep moving forward, and it seems some project's maintainers are being swamped by PRs (some good, some bad).
Whatever allows random 3rd party to 'strip-mine' existing codebases for bugs, should also be applied to new code.
Hegseth is to blindisded by macho-ism to value anything that requires patience and planning (see iran) If Fable is able to cheaply (ie less than $40k) find serious CVEs in common software, then it costs america much more to defend against it. especially as they are keeping the price of zero days artificially high.
Furthermore, of course Glasswing participants are scanning their dependencies as well. Why would you think they aren't!?
And CVE's: People actually do that now, which before they didn't. Github allowing it now, certainly does help massively. This is a good thing
Which was certainly an improvement, given that Github is in no hurry to add modules support to CodeQL.
No doubt is it a good thing to have issues reported and fixed, but CVE feels a bit like blackmailing maintainers - either you fix the issue or we get your project flagged with "security scanners".
I guess, my distaste mostly originates from randomly assigned high CVE numbers that don't reflect the actual threat. And the fact that it gives the companies which use the code "AS IS" an imaginary stick to hit open source maintainers, until they fix the issues for the company (for free of course).
But the claim of "LLMs aren't making a difference in vulnerability discovery" has been laughable to anyone who has been reading security advisories for the past 3 months. Just look at the Credits lines.
We got many high-quality bug reports, some of them with a security aspect to them. Several of them received CVSSv3.1 scores of around 9.8 from the rating agencies, but these high numbers are misleading. (Vulnerability scoring is hard, and it's pretty much impossible for a library without reference to an application that uses the library.) Looking beyond the numbers, everything reported this year (and late in last year) was pretty harmless so far.
Does this mean LLMs are making a difference? For upstream developers, definitely. For end users? Not that much yet.
Maybe the picture changes once the organizations sitting on the good findings figure out how to disclose them to the relevant upstream projects. When I read the announcement of Project Glasswing, I immediately thought that this was going to be the hardest part.
The end result is both that there are more critical CVE and that there aren’t.
This gives Anthropic a staggering amount of power. Oh it came from Mythos? We will just lose time trying to analyze it, better apply the fix ASAP
Do people maintaining serious software do this, though?
The actual, underlying problem is that software is buggy and current programming languages aren't fit for writing reliable software. There's a wide gap between the state of art in formal verification, and what is actually practiced in the industry. It's because of this general unreliability that AI has a large supply of vulnerabilities to find. The situation will only get better if software becomes reliable and written in solid foundations.
My guess is that AI will be even more useful to verify software (something like, write Lean or Coq proofs that the software is not vulnerable, things like that), rather than finding vulnerabilities piecemeal but still letting software be written in unsuitable languages, with no formal verification to prevent bugs from sneaking through.
To make it worse? AI and even Fable can make things +50% and then -50% in different places. You can trade 1 bug for another.
So just "rubber stamp" doesn't make it better.
In theory, this should be very straightforward to prove correct with many of the current tools. In practice, no one has shown us how to do it. We could even rewrite the code from a macro/#include maze to proper function calls if that's a prerequisite for analysis. At this point, I would even take a one-off analysis.
At least, that’s what most of the high-visibility users in Project Glasswing are doing.
There are bad apples everywhere, and this initiative is no exception.
If it makes you feel any better, many of us regularly meet to stay calibrated and hold each other accountable, so I’m confident in the quality of the work produced by this particular group of employees across some of the partner companies mentioned in the article.
That said, I know several people who blindly report everything Mythos finds, which is foolish, especially since the harness is a critical part of the project's quality metrics. Some of the harnesses I’ve tested are quite weak, which leads to poor results.
For example, yesterday morning I was pulled into an ad hoc meeting where a CVP was grilling me about several supposedly critical bugs that my team had reported against one of the core components of iCloud. I was genuinely surprised because we’re very strict about validation. We often even downgrade the severity of bugs when our harness can’t prove what Mythos found. After reading the reports, I realized they weren’t ours. They came from another team that had recently been given access to Mythos. They built their own harness and were using different vulnerability criteria. Fortunately, they had only started earlier this week, so I was able to stop that work.
That incident showed that not everyone involved in Project Glasswing follows the same standards. Most people do their best, but priorities differ, so it’s expected that you’ll find a few bad apples.
I wish AI labs would stop the theatrics and release their models without restrictions, but I also recognize that’s not the world we live in. For every person who wants to use these technologies for good, there are many others who would use them for harm.
In any case, while I agree that some experiments contain genuine noise, the CVE count is real.
>That incident showed that not everyone involved in Project Glasswing follows the same standards.
It genuinely felt like the aladin scene in The Dictator reading this comment.
> Its very hard to understand what you're saying with the comment
Yes, fair enough. I’m simply trying to shed some light on what goes on behind the scenes without disclosing too much information to avoid breaching the NDA(s) that all Project Glasswing users have signed. There’s a lot of speculation about the usefulness of Mythos as a security tool, so much so that even the US government got involved. Honestly, it’s so absurd that I can’t even express it in words. I thought that sharing a bit about how frustrating it is to work within this project, trying to secure software that literally millions of people around the planet use on a daily basis, while virtually everyone outside of it criticizes every move you make, would be helpful.
Many people I work with recognize the power of Mythos, just like any other model with a similar number of parameters, but most of the people I interact with agree that it’s not the ultimate panacea. I believe that it’s just vocal minorities scaring everyone into thinking that the model is some kind of cybernetic weapon.
And I didn’t even have to deal with a jumpy national government.
Wait, you guys had a RCE in Claude Code for nearly a year and didn't even release a disclosure about it and secretly patched it and swept it under the rug?
Well... It's okay, I still trust you."
So in your opinion, what would be the best off the shelf options? And secondly, how much better you’d say a purpose built one is compared to a general purpose one with a good system prompt?
Or it functionally does not exist.
(No, long hashes with an equally mythic promise of reproducibility don’t count)
1. Someone with early access to Mythos leaked it to the bad guys.
2. Cybercriminals are getting enough mileage out of alternatives to Mythos to create exploits far more quickly, even though they don't have access to Mythos.
My own guess is that it's a combination of #2 plus vibe-coding degrading software quality at multiple layers, open the door to sophisticated exploits, but I have no insider access to Mythos so am just guessing. Maybe someone with Mythos access might say why they think this vulnerability spike happened when it did.
3. People were already sitting on vulnerability reports from their own tools and threw them over the wall.
They were worried about getting scooped. They had to consider Mythos' alleged capabilities as a tool, and Project Glasswing potentially establishing a well-run disclosure and remediation process. Both could devalue preexisting results.
https://www-cdn.anthropic.com/7624816413e9b4d2e3ba620c5a5e09... (pg. 13)
It's almost like... Finding bugs is a good thing.
That's not to say that we aren't introducing new bugs, but I'm only addressing Mythos and Glasswing.