Hacker News new | past | comments | ask | show | jobs | submit

Tracking Anthropic-discovered vulnerabilities

https://www.vulncheck.com/blog/anthropic-glasswing-november-update
I received 9 reports of Fil-C issues from Anthropic

All of them were real bugs. None of them were false positives.

The quality of the reports was exceptional. (My baseline is doing security defense on a browser engine, so my baseline has a large sample count and is probably representative of what experts are capable of.)

The quality of the proposed fixes was alright. I took some of the fixes verbatim. I used most of the fixes as significant inspiration for doing it my way.

The quality of the test cases was exceptional.

Maybe I’m special somehow! But I just want to call out the enormous chasm between what I saw of anthropic’s capability and what TFA says

A simple reason could be the age of the codebase. New code contains more serious bugs, and younger projects are made up of more new code than more mature projects. In older code, especially well-used older code, many serious issues have already been found and fixed.
loading story #50449391
loading story #50449818
Linux maintainer is extremely unhappy with the high false positive rate from Mythos vuln: https://m.youtube.com/watch?v=NnV_cWeoo5Q&pp=0gcJCVgCo7VqN5t...

I think someone who likes AI thinks it’s good, someone who doesn’t, doesn’t think it’s anything impressive, and concretely nothing of any significance has happened to the world, certainly nothing like the crowdstrike shutdown so I don’t find the capabilities to be anything impressive.

loading story #50449809
> Linux maintainer

I wonder what it's like maintaining a project where you regularly get competent contributions. No wonder they are less impressed with AI - they are the 0.1% of maintainers who had something better.

loading story #50449229
It’s true that I’m an AI adopter. My psychosis is pretty advanced. I’m running four clankers in parallel right now.

The 9 bugs I got were clear security bugs under the Fil-C definition of memory safety. One reason why my experience could be an outlier is the effort I’ve gone to defining what the security properties of Fil-C are, to the point that there’s a crystal clear falsifiable boundary. So the bugs aren’t a matter of opinion or judgement. That helps clankers and it helps me when screening the bugs.

> concretely nothing of any significance has happened

This is a good point, but “cyber apocalypse dooming is an exaggeration” is a different statement than “bugs found by Anthropic aren’t real”. I agree that the dooming is an exaggeration. I don’t agree that Anthropic’s bugs suck.

Two reasons why bugs-found-by AI-are-really-scary and nothing-is-happening can be true at the same time:

1. Anthropic is sharing the bugs found by their most capable model with defenders, not attackers. Defenders are working overtime fixing those bugs before the embargo runs out.

2. The attackers that have access to Anthropic-class capability are using their bugs surgically. They aren’t using them so widely that folks would notice. That strategy is business as usual for advanced attackers

I obviously don't know if this applies for the Fil-C bugs but what we saw in Rust is that there's plenty of "technically that's not OK" which is very distant from "this will actually cause real world problems" https://forge-blog.github.io/posts/rust-std-memory-safety/

For example it's definitely not OK that you can impl Pattern in a way that causes non-UTF8 data in a string with safe code. But you probably didn't let random attackers impl Pattern, on a nightly Rust where that's even possible, and so that's not going to cause problems in our real world - even though it's wrong and must be fixed.

loading story #50449706
loading story #50449371
> One reason why my experience could be an outlier is the effort I’ve gone to defining what the security properties of Fil-C are, to the point that there’s a crystal clear falsifiable boundary.

Building software boils down to defining things correctly. So, it sounds like you did most of the work here. Imagine that you took your definition and moved it into a formal specification (programming language) and then ran that to verify the security properties of your system. What's different?

Or, imagine that you took your original code as your specification language and then iterated on your understanding of it until it was correct. What's different?

Attention highlights and resolves bugs, so that's the baseline. In order for AI to get value, it has to be some kind of multiplier on your attention, but the reality is generally the opposite.

AI is a legitimate step change in every domain of knowledge work, cybersecurity included of course.

OP's post adopts a deliberately skeptical angle, it is a blog post for a company that advertises the ability to spot and patch vulnerabilities. They have an intrinsic motivation to minimize the believed effectiveness of wholesale SOTA-model cyber superiority which erodes their moat.

I suspect the gap comes from whether or not you're being used for marketing/IPO bubble driving. I love Fil-C, and its still a small enough project that it doesn't make front page news if a problem with it is discovered. So I think the gap comes in in that they have no incentive to massively drum up the number of security vulnerabilities that they find, by publishing a huge number of false positives that then get quietly retracted

By contrast, when <tool> announces they've found XXXX vulnerabilities in Linux, it makes the news literally everywhere. Even if 0% of them turn out to be real, it doesn't matter - they've already gotten what they want out of it which is the round of coverage about how incredible <tool> is and its the end of the world

I have these things running 24/7 working on apks. They are extermely underwhelming, I spend most mornings annoyed looking at hallucinated/incomplete/insignificant findings from overnight.

Im about ready to stop using them overnight in this autonomous fashion. Its a great "intelligent" fuzzer but pretty mediocre when its steering the ship by itself.

loading story #50449567
[flagged]
loading story #50449910
loading story #50449927
As someone working at a bigtech co that has spent every single working day (and many weekends) since the launch of Mythos patching serious, company-ending type of security issues, these types of posts really irk me.

Public datasets of CVEs being underwhelming doesn't mean much if all of the issues are in private company codebases that will never get a CVE number assigned and will never get a fancy blog post. You're never going to hear about them, and the people working on them probably can't tell you about them, but that doesn't mean they don't exist.

We're all worried about OSS having security issues because of how widely used things like PHP or curl are... but the same can be said about email providers, document collaboration SaaSes, payment processors, etc that millions of companies depend. Those companies will never be in datasets like this, and they'll never publicly disclose how many issues they found.

Yeah I am much more worried about some critical vulnerability in, say, the controller logic for pumps at sewage treatment facilities vs. a sandbox break in Chrome (which will be patched well before the blog post...). The broad issue is that you can turn DeepSeek-v6-unhinged loose on an arbitrary IP and exploit ~everything that is not developed and actively maintained by a billion-dollar company
loading story #50449323
loading story #50449399
loading story #50448886
loading story #50448837
loading story #50448676
loading story #50448961
loading story #50448671
loading story #50449557
loading story #50448916
loading story #50449282
loading story #50448640
loading story #50449017
loading story #50449871
loading story #50449188
loading story #50448848
The PHP2Shell vulnerability ended up being paradoxically comforting for me.

They turned frontier models loose on PHP, and the big one they found was based on a previously known logic flaw that was extremely difficult to exploit. Which makes sense: hence the need for frontier models.

And in the wild, while there have been many attempts and a few simple demo successes, the practical impact has seemed to be small, seemingly constrained by the length of the chain and the diversity of PHP configs.

In short, it was indeed a major vulnerability, but not magic (in the Arthur C Clarke sense).

I think ultimately the fear comes down to: do you believe that code can be secured. I recognize that there is probably no objective way to deductively prove it because of the Halting Problem etc. But if one believes code can be constructed to operate to spec, then there must be a limit to the damage an LLM can do, even a very smart one.

I think we are going through a phase where a lot of known triaged code shortcomings will get exposed and hopefully fixed. Sucks while it is happening. But not actually the first round of this type of evolution. And ultimately I think as before, we will come out the other side with more secure and durable technology.

loading story #50448947
The halting problem is a product of a Turing-complete model of computation.

If we want perfectly secure systems, then perhaps we don’t want universal and general purpose ones.

loading story #50448996
loading story #50449726
One can imagine a world in which Rust allows a `decidable` block and code has stricter guarantees within it.

I imagine it would be a nightmare to work with.

loading story #50451148
loading story #50448518
loading story #50448499
loading story #50448774
loading story #50448560
The blog is misleading because it tries to characterize Project Glasswing's effectiveness through use of a tangentially related data source. A Project Glasswing vulnerability discovery most often occurs when a Glasswing partner points a Mythos-class model at its own, often proprietary, software. The data source (aka "ledger") is only for the Anthropic coordinated vulnerability disclosure program for open source software: in other words, Anthropic itself pointing a Mythos-class model at an OSS package, and then notifying the maintainer afterward that it had done this, and had findings to share. This OSS work is certainly useful, but the number of fixes reflects - in part - limited time availability by volunteer OSS maintainers, and Anthropic sometimes working without knowledge of the OSS project's threat model (the threat model is explicitly requested in the newer oss-scanner effort). Percentage fixed is often much higher for use of Glasswing with proprietary software, e.g., https://blog.cloudflare.com/cyber-frontier-models/ "Our research with Mythos Preview was conducted in a controlled environment against our own code; every vulnerability surfaced through this work was triaged, validated, and remediated where action was needed under Cloudflare's formal vulnerability management process."
loading story #50449512
There's an anecdote about curl, but I'm not sure if there's enough in here to draw conclusions from. 20% of vulnerabilities have been made public, and many of those are marked as "withdrawn" or "duplicates". However, it's unclear whether the remaining 80% have not been made public because they're not fixed or real. In other words, this is analysis of survivors (public); not much can be said about those still under embargo.
I'd expect the remaining 80% are delayed not because there's something statistically special about them, but from the massive workload thrown at humans in the loop.

Anthropic needs to teach their systems to propose a fix too. Detecting a coding problem and proposing a patch is what we should expect from a company with supposedly the best coding LLM.

loading story #50448231
loading story #50448211
loading story #50448258
loading story #50447773
loading story #50448229
> So far, only 2 of the 442 have been exploited in the wild, just 0.45%.

> almost none are being exploited

Isn't the whole point of glasswing to patch stuff way before it can be exploited? If the patched code is distributed quickly- there's no opportunity (or incentive) for bad actors to craft and distribute an exploit. This reads like an attempt to spin them as not being "real" vulnerabilities.

loading story #50449020
It is bad if this points to a general pattern of AI being better at finding than fixing vulnerabilities. The larger that ratio, the harder to secure all the things. The current stat from this experiment is 37,966 to 217. Lots of false positives, but not enough to change the big picture. I hope they didn't apply equivalent tokens to both sides, or AI may be better at demolition than construction.
loading story #50447893
loading story #50448104
loading story #50449097
loading story #50447825
As someone downstream of the company in the posting, i can confirm the tsunami of AI generated vulnerability reports. And so thr human maintainers are stretched even thinner, and most of the bugs dont matter.

The good thing is the push towards an exploitability rating: If you have a vulnerable piece of software on your system, but it isnt running, it isnt critical.

loading story #50450831
> Of Anthropic’s 37,966 reported findings, only 7,349 (19.4%) have been made public and just 217 have been marked fixed.

So the article is making a sweeping statement based on the 19.4% of publicly disclosed CVEs?

That statistic suggests the opposite. I'm sure government is aware of many back doors they keep secret and prefer them to remain secret.

loading story #50447536
loading story #50448440
This is very much inline with Greg Kroah-Hartman the long-time Linux kernel maintainer's view Anthronpic's Mythos audacious claims its cyber capability. Majority of those "findings" were way out of proportion and merely "pattern matching" previously discovered methods of exploitation.

[1] https://news.ycombinator.com/item?id=50342622

[2] https://news.ycombinator.com/item?id=49929391

loading story #50450303
The post seems misguided or misdirected in my opinion. Not discounting the fact that the frontier models may find existing bugs, that some are labelled at the incorrect level, even some being a non-bug -- fact remains they are discovering vast numbers of issues. It also isn't the job of Anthropic or OpenAI to fix everyone's bugs, they are doing everyone a courtesy to spend their time identifying them in the first place. The bigger issue appears to be that they are finding more bugs than the developer capacity to can address.
Does anyone know how Glasswing relates (quality-wise) to https://github.com/anthropics/oss-scanner ?
loading story #50449896
As AI gets better, it feels more and more like each person gets to hold a bomb in their own hand, but at the same time it feels like having a bomb that can just go off in that hand.
In my opinion, what tells a lot about AI provider AGI claims versus reality is the difficulty to have LLM provide the fix to issues.

For PHP2shell vulnerability for example, there was "patched" .deb (and equivalent) packages only for the most recent and most trendy distributions but countless older versions of distributions and php versions were like abandoned without simple solution. I would have guess that "patches" and pre-built fixed packages would be flooding the world. And with just a prompt of one line, most servers would be properly patched. But no.

loading story #50448521
Sankey diagrams are ruined for me
Well in cases like these, it’s not the many that matter, but the few. Measuring in aggregate is not conclusive.
> made me wonder whether this was more of an overhyped marketing campaign.

This is the entire premise of LLM hype wave. Or any overhyped tech that tries to force its way into every aspect of life.

Very interesting that the conclusion of the article is so tightly aligned with the VulnCheck's business model! It's almost as if this is just a thinly veiled advertisement...

> The CVEs are a sliver of this year's total, almost none are being exploited, fixes have stalled while duplicates and withdrawals pile up, and the triage burden is shifting onto the open source maintainers Glasswing promised to help. The receipts keep coming in. They still don't reconcile.

> VulnCheck is helping organizations not just to solve the vulnerability prioritization challenge - we’re working to help equip any product manager, CSIRT/PSIRT or SecOps team and Threat Hunting team to get faster and more accurate with infinite efficiency using VulnCheck solutions.

I think the most obvious chicken little sign has been that we've had no catastrophic exploits in the past year due these findings.

Sure LLMs have helped reduce the attack surface and we patch things faster too, but I was really expected a few more Supermarket-level bangers.

loading story #50448652
loading story #50447633
loading story #50448570
loading story #50448160
loading story #50447694
Hard not to draw parallels with Deepmind’s GNoME project which found millions of new “materials” most of which turned out to already exist or be garbage basically.

https://pmc.ncbi.nlm.nih.gov/articles/PMC11044265/

The common thread is asking humans to do the verification work, which is the hard part.

loading story #50449060
This is literally an ad for a service that helps you prioritize vulns! It is incredible how often an alleged study like this turns out to be an ad for such a service. "Businesses finding ROI hard to demonstrate" -> ad for a product that helps you demonstrate ROI. Etc.

> VulnCheck is helping organizations not just to solve the vulnerability prioritization challenge - we’re working to help equip any product manager, CSIRT/PSIRT or SecOps team and Threat Hunting team to get faster and more accurate with infinite efficiency using VulnCheck solutions.

My AI Maxxer team mate gets politely ignored now when they put up a bunch of completely random, irrelevant "findings" on my PRs. Probably some model like Fable 85.2.12 can find every nuanced "gap" in my dev-env-only shell script, but I'm not fixing that when there is no production impact and I'm trying to make merge the pipeline to make your containers work.

/Rant

loading story #50451353
loading story #50452326
I rather like how the folks squabbling about the stats about the report stockpile are ignoring the stats about OSS Scanner. [0] The >50% false positive rate for Curl agrees with Greg K-H's report from this year [1] of a very high false positive rate from Glasswing/Fable. And -as he mentioned in his talk- people refused to pay money for Qualys because its 20% false positive rate was way too high. The only way you're going to get folks to pay for Anthropic's vulnerability scanners is if they're either incapable of understanding the details about its performance or they don't give any fucks about saturating their bug-fixers with garbage reports.

[0] <https://www.vulncheck.com/blog/anthropic-glasswing-november-...>

[1] <https://www.youtube.com/watch?v=NnV_cWeoo5Q>

that's hilarious, they made such a big deal of the cyber scare

no moat

There was a lot of hype early this year. Mythos, openclaw, gastown. And now they’re basically completely irrelevant. Things move so fast.
loading story #50448529
Huh? Is VulnCheck talking about itself? I’ve come across many false CVEs associated with VulnCheck over the past few months, including this one: https://github.com/advisories/GHSA-vfj7-8cjw-p6xm
Expected this to happen maintainers overloaded with issues majority of which are nothing burgers.
And yet every single company is getting hacked. So some of the findings (presumably non-Glasswing) are clearly quite whelming!
The biggest problem is that AI boosters will of course raise their adhoc evidence and they are fucking loud. The same people who insist there's no need to review code because it doesn't need review. But, fuck. How do they are so sure about that if they don't review, it is just circular thinking over and over again.
Does the author expect that every company using Glasswing/AI is going to credit the AI directly? I would not expect Microsoft or Cisco to credit Anthropic if one of their internal teams uses AI to discover a CVE in their code.
Attribution/reporting is probably part of the conditions for these companies to get access.
AI models generating slop findings? Who ever could have predicted this?!