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
pron 10 hours ago [-]
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.
pizlonator 10 hours ago [-]
It’s not a reason for the wide chasm though.
If you told me that some significant number of Ant findings were duds, then I could reconcile that with what I saw first hand.
But TFA is making a more extreme statement
viraptor 6 hours ago [-]
One thing I should've expected in those reports but didn't is that some maintainers end up nitpicking the reports instead of just doing the best to address the issues. When discussing the LLM code reviews, one author was arguing the security reports are really bad - it turned out that I completely disagree on the judgement they made. Instead of accepting that something can be improved, they argued how unlikely something is, how the project doesn't make this kind of guarantee, how that's an API user error... instead of saying:
- Yeah, we could check the parameter here. Currently we don't return any result so let's add a success/failure response rather than silently failing.
- This is a highly unlikely situation, but let's harden it anyway in case things change and it bites us in the future.
I don't know how many end up in that situation, but it was a whole category of people claiming the LLM reviews are bad, that I haven't really considered before.
grim_io 4 hours ago [-]
Yeah, I don't think we can ignore the small issues anymore.
No matter how unlikely the issues seem to us, an LLM will happily chain dozens of them and do complex timing attacks to eventually gain access.
aprilthird2021 9 hours ago [-]
The reason is that's just how AI is. It has a very jagged edge of experience. In some ways it's bizarrely wrong and in some ways it seems like a mystical crystal ball.
intended 10 hours ago [-]
Likely difference between individual experience and group experience.
Useful to figure out if there are other cases like yours, so then commonalities can be inferred.
pizlonator 10 hours ago [-]
Totally
I’m just sharing my data point
gwd 1 hours ago [-]
All of the bugs Claude (Fable or Opus) have noticed as I've been working in Xen have been real bugs; but many of the potential security issues were really obscure combinations of things.
For instance, it noticed that during CPU offlining, a page was freed and then something specific was written to it afterwards. Technically a use-after-free; but to exploit it you'd have to somehow know that the CPU was going to be offlined (not something that normally happens), then try to jigger the page to be allocated by someone such that the later write (also not controlled by you) actually did something you wanted.
Or, if you had a machine with over 5TiB of RAM, but for some reason your control plane was only assigned a single physical CPU, and then an attacker organized memory on boot a certain way, then it could crash the system.
The ones above ended up on the "not a security issue" side of the line, but a handful of ones ended up in the "is a security issue" side. These are all kind of excruciating, because on the one hand they seem so unlikely to even be able to trigger that they're hardly worth thinking about; but on the other hand who knows, maybe there are situations where it could happen.
NB these are just things Claude pointed out to me as I was working with the code, not things Anthropic reported.
dwohnitmok 9 hours ago [-]
That's interesting. While the curl maintainer seems to have been underwhelmed with Mythos 5 in particular, it looks like he also backs up your account of high-quality AI reports (although unclear if these come from Glasswing or elsewhere) at this point.
> The slop is gone
> A sizeable portion of users seem to still believe we still suffer from a lot of made up and hallucinated reports by these AIs. We really don’t.
> Almost all the stupidity and lies we saw in the vulnerability reports made by AIs in the past have ceased. Since spring 2026 the slop reports are practically gone. Our current challenge is much harder: high volume, high quality.
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.
derefr 9 hours ago [-]
> and concretely nothing of any significance has happened to the world
I would hypothesize that all the long-held "easily discovered if you look in the right place, but never reported and so never fixed" 0days in operating systems that criminal gangs and militaries have been relying on (to do cyberattacks with, unlock devices for forensic data recovery with, etc.), are increasingly being exposed and cleaned up, much faster than new such exploits can be discovered; and that this may have given an edge to whichever side of these conflicts don't rely so heavily on hacking the other to achieve their goals.
wanderlust123 3 hours ago [-]
What do you mean nothing of significance has happened to the world?
pizlonator 11 hours ago [-]
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
tialaramex 10 hours ago [-]
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.
sheepscreek 9 hours ago [-]
I'm speculating out on a limb here, but maybe the Mythos zero-days that were developed into working exploits involved a few of those "usually won't cause real-world problems" happenstances.
A model with all the world's knowledge might know exactly how to weave them together into a successful exploit. And if tomorrow's models are even more capable, perhaps what we're experiencing now is just a fire drill for what's coming.
pizlonator 10 hours ago [-]
Most of the bugs were things that fall into the “won’t cause real world problems” category.
But they were all things that unambiguously violated the Fil-C promise
d0liver 9 hours ago [-]
> 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.
zulban 11 hours ago [-]
> 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.
NewsaHackO 10 hours ago [-]
I see it the other way; Linux is a huge project, but being a solo maintainer for a mid-sized project like Fil-C is a different level than one of dozens of maintainers for a large project like Linux. Sort of like being a solo founder for a semi-successful startup is different than being a rank engineer at Google.
atleastoptimal 10 hours ago [-]
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.
lifeisloving 10 hours ago [-]
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.
cheesecompiler 9 hours ago [-]
can you elaborate?
20k 9 hours ago [-]
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
soon_to_be_sb 4 hours ago [-]
>I received 9 reports of Fil-C issues from Anthropic
Probably curated
seanjhkwon 16 minutes ago [-]
[flagged]
kmacdough 11 hours ago [-]
[flagged]
dang 8 hours ago [-]
You broke the site guidelines with this post. Can you please make your substantive points without swipes and avoid crossing into personal attack?
Your response seems a bit overwrought, to call their claim nonsense solely because they used the word "representative" to describe their experience (and they did only say "probably representative"). They're not making a scientific claim, they're reporting an observation about 9 bug reports.
voxl 11 hours ago [-]
[flagged]
enthuseyourcurb 12 hours ago [-]
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.
levocardia 12 hours ago [-]
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
varenc 10 hours ago [-]
> 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
Agreed. My fairly obscure company got hit by something like this last weekend. What stood out was the speed: attackers found something small, used it to uncover something else, and pivoted to clever exploits for the new thing within minutes. It hit a dozen of our apps in parallel within the span of a day, from a rotating pool of residential proxies, Tor, GCP and Cloudflare IPs.
I'm fairly confident it was LLM-driven. The payloads and throwaway accounts had names like "PT59553 TEST IGNORE" and "PocCorp1659r2", and it adapted to error messages the way a person reading them would, just never sleeping. A non-tech company with 100x the surface area and much more valuable data could be in big trouble.
Of course I used LLMs for the defense too, and they were amazing at log forensics and fixes. The annoying part was when I asked Opus 5.5 for clear repro cases of exactly what the attackers did, I hit the cyber safeguards. Opus was trying to keep the exploits for my own bespoke applications away from me. It was happy to fix things of course, but I worry if it really can't 'think' about actual exploits, its fixes will be less informed.
anatolii1309 6 hours ago [-]
[flagged]
monster_truck 10 hours ago [-]
the broad issue is actually that those are connected to the internet at all and there is no real enforcement or penalties for it
billion dollar companies are not exempt from this, in fact they tend to be the worst offenders
lifeisloving 11 hours ago [-]
[flagged]
mech422 11 hours ago [-]
we've already had water treatment plants hacked and the amount of chlorine in the water changed. Florida ended up with dangerous amounts of lye being added to the water and was saved by an employee that noticed the change...I am worried, no airgaps to be found..
oh great..I'd almost forgotten about that... what I found really funny was they just infected every USB key that vending machine had until a worker bought one...No fancey targeting, just cheap usb keys and patience.
lifeisloving 10 hours ago [-]
Have you tasted Florida water, it could probably use some extra chlorine. They dont exactly invest that much in public health/infrastructure, im not surprised this happened in Florida. Its a careless state with careless politicians.
Im still not worried about it. There's thousands of water treatment facilities in the USA and you've surfaced two occasions.
Ya'll should try actually breaking into something semi secure with an LLM, its not as easy as you might think. Seriously go try it, if you think its so easy there's millions of dollars to pick up off the floor on bugcrowd or h1. Seriously, please go give it a go.
Secondly, maybe the USA should stop committing mass murder across the globe if we don't want to be the subject of retaliatory attacks.
mech422 9 hours ago [-]
I actually 'surfaced' attacks in 5 states, and you only read two of them...not to mention Canada and Israel. Also, you're acting like you think its some script kiddies gonna try this stuff. It will be state actors, and was mentioned upstream in the stuxnet comment.
lifeisloving 7 hours ago [-]
I dont think it's going to be script kiddies, but it sure does seem like everyone worried about this issue thinks anyone can hack critical systems now with a claude sub.
Do you think state actors are only capable of harming you now because of llms??? They don't need llms lol.
I would argue that systems were largely more vulnerable 5 years ago than they are now. Especially at a municiple level.
There seems to be a lot of "strategy of tension" being employed in these news cycles surrounding security and AI. Dont fall for it. You're fine. Systems are more secure now than they ever have been in the past.
But on the Israel note, thats awesome I hope more of that comes their way.
mech422 6 hours ago [-]
I never mentioned LLMS, a bunch of the attacks I listed pre-date LLMS, what makes you think I care about LLMS ?
lmz 11 hours ago [-]
Just like the European freezers and refrigerators.
pants2 9 hours ago [-]
"should be" is doing a lot of work here.
Airgaps don't solve everything either. Stuxnet was successful at destroying air-gapped machines.
One example they use in the blog post is curl. Not maintained or developed by a billion dollar company.
I suspect open source projects are better off than proprietary software - they already have many eyes on them, whereas commercial software that’s not a prominent and profitable target (e.g. windows, ios) hasn’t had much attention until LLMs made attacking them significantly easier
pixl97 11 hours ago [-]
The average enterprise software is swiss cheese. It seems the hacker news type that likes to post just doesn't realize how much business/enterprise software exists out there. An F100 company has thousands, maybe tens of thousands of applications that you've never heard of and never will unless you work for them. Industry has applications ran by relatively few people, but it's keeping processes that make the modern world work alive.
Worse is everyone is like "Well, this stuff is protected or air gaped". Yea, it's behind firewall, or even private networks commonly, but the moment you get inside that network you have tons of lateral movement and could cause unbelievable damage in minutes.
DenisM 11 hours ago [-]
> I suspect open source projects are better off than proprietary software - they already have many eyes on them
This has been disproven by the sordid history of OpenSSL. It was open source, critical, and full of holes.
Single datapoint does not prove anything at all, but it is a data point.
throwaway2037 11 hours ago [-]
> Not maintained or developed by a billion dollar company.
Directly? No. Indirectly? Yes. They are mostly funded by billion dollar companies.
kennywinker 7 hours ago [-]
Mostly funded is different from “maintained” or “developed”.
Afaik everyone working on curl has a day job.
da02 12 hours ago [-]
Have you seen any patterns for the causes of the error you have seen? For example, more training for developers? Or maybe just systems were really very complex that led to bugs?
bobkb 11 hours ago [-]
With code public many of the actively used and maintained open source projects have better code quality than proprietary or big MNC ones. Forget Mythos level models but even smaller models are able to find large number of issues in closed source tools in my example. One reason obviously is the peer review and quality checks by users/hackers/maintainers over the years.
12 hours ago [-]
aprilthird2021 9 hours ago [-]
> these types of posts really irk me.
They shouldn't. AI is great at some things and underwhelming at others, and it's never predictable if you're going to get the great response or the silly one and when you'll get it and over what topic. And you and the author combined are illustrating one scenario where that jaggedness shows up.
wizzledonker 11 hours ago [-]
Possible you might be believing the LLM too much. It seems to flag so many “critical, company ending” security issues, the ones surviving any semblance of scrutiny I’d estimate at 0.5%.
Make sure you’re still thinking.
tomhow 6 hours ago [-]
> Make sure you’re still thinking.
Please avoid patronizing barbs in comments on HN. I can believe you didn't intend to be mean, but it's easy for these things to be misinterpreted on a text-only message board. https://news.ycombinator.com/newsguidelines.html
wizzledonker 6 hours ago [-]
You are right of course, for posterity I didn’t intend this as a ‘patronising barb’. It’s more intended as general advice, which readers can agree or disagree with.
philipwhiuk 3 hours ago [-]
Do you have any evidence for the 0.5%.
2 hours ago [-]
grim_io 11 hours ago [-]
[flagged]
misterderpie 8 hours ago [-]
I would agree with the sentiment of the commenter though. Software bugs in proprietary software are real, but LLMs tend to overstate their criticality, and/or inside knowledge is at times needed to exploit those.
We've sure seen that LLMs can make good assumptions about blackboxes and, unlike humans, are able to try many paths in a short time. However, one can't neglect that doomsday prayers have been present before the dawn of AI, and rarely companies got hacked.
From anecdata, the human is still most often the culprit for breaches, not the "We managed to penetrate that one byte often enough" exploit.
wizzledonker 9 hours ago [-]
I'm replying to a new, green account, immediately raising suspicion. Secondly, we're both random internet strangers. Why believe one person over another based on two easily falsified claims? In this discourse my experience should be as valid as any other.
as a bystander not even working in the sector, your witnessing is exactly what I was worried for.
if an agent is wily enough to defeat a security it should also be wily enough to cover its tracks, otherwise what's the point?
bertt 10 hours ago [-]
[flagged]
elzbardico 9 hours ago [-]
[flagged]
Zagitta 11 hours ago [-]
[flagged]
killerstorm 11 hours ago [-]
If $typical_software_stacks have had enough "company ending" security issues ... maybe the whole industry have been seriously misguided for decades? Clearly they cannot have taken security serious in any way shape or form.
rester324 10 hours ago [-]
That's correct, but this won't dismiss the parent commenter's argument. A world wide industry cannot be held accountable, but a for-profit company's executive board can be.
peanutz454 11 hours ago [-]
Neither "shutdown the company with bad code" nor "because there is bad code out there AI driven security findings are unworthy" is the conclusion I would come to.
rester324 10 hours ago [-]
Yeah. But how about fining the shit out of companies with found vulnerabilities and data breaches? I can guarantee you they would all harden security in a day if the fines were costly enough
peanutz454 10 hours ago [-]
I'll stand with you on this one. I used to work for a cowboy company and I disliked being the minority that actually cared about stability while the head honcho did lip service to the concepts everyday.
redanddead 8 hours ago [-]
[flagged]
tehjoker 10 hours ago [-]
[flagged]
jknoepfler 11 hours ago [-]
[flagged]
jeremyjh 11 hours ago [-]
I don't think it matters. You have to address it or it just continues to generate noise. People aren't great at predicting what could really be exploitable, so who is going to sign-off on ignoring it at a large company? And there is real risk there - even if only a tiny fraction are truly exploitable in a way that would cause real harm you just don't know which are which.
Personally, I would be absolutely astonished if there were not numerous catastrophic security flaws in LOTS of private codebases in even the best engineering orgs. How discoverable are they without access to the code? Well - how many people have access to that code?
senordevnyc 11 hours ago [-]
You sound like you’ve already made up your mind. Why would anyone waste their time trying to convince you, random internet stranger? It was just someone sharing their personal experience, which you’ve neglected to do, I might add.
jknoepfler 10 hours ago [-]
I've only made up my mind to the extend that I'm naturally skeptical of anyone selling anything, and to the extent that I've worked in cybersecurity and know how the sales engine works.
Beyond that, I'm confused. OP gives data supporting the idea that security concerns have been a puff-piece PR stunt. Glasswing's numbers are fake, and beyond that why on earth would a company not divert resources to processing vulnerabilities if they were sitting on a PR goldmine?
The response is "trust me bro, I've been working hard to fix stuff for a private company." Which doesn't tell us anything.
The OP gives us ample reason to believe that this commenter has been wasted their time on non-issues caused by LLM slop-reporting. This is consistent with my professional experience (and I'm confident resonates with the experience of many who actually work in the field).
The commenter theirself just says "trust me bro, private is different from public" which I do not have reason to believe.
I work for a private enterprise that has been deluged with security issues that we are fixing while adding zero value to the company due to corporate's response to "Mythos."
We are finding that almost none of these issues are valid.
I would love - LOVE - to hear some kind of valid, quantified, well-argued justification for the titanic shift of resources away from productivity and towards security.
I would love to look at actual data, or for you to make an actual argument, or for someone to make some actual sense on the cybersecurity doomsday front. I engage in good faith with good faith arguments. I have not heard any.
snowwrestler 13 hours ago [-]
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.
Paracompact 11 hours ago [-]
> I recognize that there is probably no objective way to deductively prove it because of the Halting Problem etc.
There is. But it will only be reliable if every transitive dependency of your codebase, all the way down to the hardware level, has been formally verified. Failing that, you have to rely on opaque contracts at the boundaries, and those are just promises that may be mistaken.
The Halting problem, Rice's theorem, etc. only apply if your goal is to automatically and completely deduce properties or their violations for arbitrary programs. If your goal is simply to prove security and correctness properties for well-understood classes of programs in industry, then there are no fundamental obstructions.
xelxebar 10 hours ago [-]
Formal verification is not magic. It can execute deductive proofs, but the relevance and utility of those results is a question of human values. Spec bugs are a thing. Bad design is a thing. Out-of-scope usage is a thing. Even a halting oracle won't help with those.
Den_VR 12 hours ago [-]
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.
Paracompact 11 hours ago [-]
The bar for Turing-complete is very low. The halting problem is to programming as Godel's incompleteness theorem is to metamathematics. Yet no one is seriously suggesting that we downgrade to axiomatic systems incapable of expressing Peano arithmetic, nor that our current axiomatic systems are impractical for proving theorems.
We cannot automatically and completely verify nontrivial semantic properties of arbitrary programs written in a Turing-complete language (Rice's theorem), but as long as we as humans can intuit correctness arguments for our programs, then formal methods will apply to it. Of course, declarative rather than imperative programming semantics tend to result in simpler correctness arguments, sidestepping reliance on global state and convoluted loop invariants.
keybrd-intrrpt 9 hours ago [-]
And maybe we discover that perfectly secure systems are not useful, or fun, or otherwise enjoyable to use.
Maybe the digital equivalent of being locked in a doomsday bunker eating only white rice doesn't produce interesting software experiences.
strken 10 hours ago [-]
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.
Den_VR 4 hours ago [-]
Software “engineers” aren’t responsible for their code the same way professional engineers are. Yet, I’d prefer the embedded system for the supermarket freezer were a nightmare to work with, over a society that is a nightmare to live in because of “cyber.”
soulofmischief 12 hours ago [-]
I think the more fundamental question than "can code be secured" is something along the lines of "can we properly measure the security of the various components of a sufficiently codebase". Security consultants have workflows but ultimately everything is ad-hoc and suffers from cominatorial explosion, and what's missing is the security equivalent of Lean, a real formalized effort to prove security. There have been many attempts, of course. One of the great problems of our era.
soulofmischief 5 hours ago [-]
*sufficiently complex
timr 12 hours ago [-]
Thus far, these agent vulnerabilities are all demonstrating million-monkey intelligence, rather than "super" intelligence, in the sense of some swarm of robo-Neo super hackers.
That's consistent with my experience using them for coding, where even the best models mostly work by being persistently midwit (with infinite knowledge) more than individually brilliant.
One corollary of this is probably that any project that has had an army of actual monkeys pounding on it for years is likely more resistant to LLM attack than one that has not. Everyone is worrying about individual robot geniuses finding obscure vulnerabilities in Linux, PHP, Python, etc., but they should probably be more worried about the permutations of less-known software floating around their systems.
fwlr 12 hours ago [-]
“LLM” may not literally stand for “Lots and Lots of Monkeys”, but this intuition can nevertheless take you pretty far!
bee_rider 12 hours ago [-]
The expectations of AI models in security really do seem to be magical in a way that, I think, obscures what needs to be done. Of course AI can’t magically create exploits that somehow drill through otherwise secure systems, because computers don’t work that way. It’s just a matter of not taking for granted things that worked in the past, like downloading code from the Internet and running it in a super-duper secure sandbox.
A computer that isn’t connected to anything (make sure to disable Bluetooth and the microphone) is already safe. I bet eventually we’ll be able to serve static HTML pages safely eventually. Maybe not images. Font selections might have to be pretty restricted. But, at least we’ll have the useful part of the internet back.
pixl97 11 hours ago [-]
>A computer that isn’t connected to anything... is useless.
Just get rid of the computer at that point.
i2talics 12 hours ago [-]
> and hoppefully fixed.
Well, the report you're replying to doesn't make me so hopeful: "7349 findings made public, 217 (.5%) fixed"
rurcliped 12 hours ago [-]
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."
geraneum 10 hours ago [-]
> tangentially related data source
The used curl project as source which’s received mythos reports directly. What’s “tangential” about it?
dfee 14 hours ago [-]
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.
ASalazarMX 13 hours ago [-]
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.
loeg 13 hours ago [-]
> 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.
Of course it's trivial to have an LLM generate a fix, too. They probably do. It doesn't mean a project (1) wants to take an LLM-generated fix at all, or (2) can immediately commit an LLM-generated fix without review (which takes time).
MBCook 12 hours ago [-]
Maybe not. And that’s totally fine.
But right now they’re not even offering one. They’re just putting the burden on the project without even trying to help fix it.
They have all the resources in the world, and they won’t even try.
And that’s of course assuming it’s a real bug, as we’ve seen a ton of them don’t seem to be. The last time we went through this, curl reported not only that a bunch of them weren’t bugs, but some of the bugs were listed previously on their mailing list, and that’s probably where the LLM got them.
So not only is it finding small bugs. And nonbugs. It’s reporting previously found bugs.
Pilling work on maintainers. Over and over again. To help? No. To make big numbers to show off for their IPO documents.
loeg 9 hours ago [-]
> But right now they’re not even offering one. They’re just putting the burden on the project without even trying to help fix it.
> They have all the resources in the world, and they won’t even try.
Claude is perfectly capable of fixing most vulnerabilities; if that's what maintainers want, they can just ask for it. If the concern is cost, Anthropic offers a Claude for OSS program.
The reason Anthropic isn't proactively sending patches is, I suspect, that those patches would not be welcomed, because trust in the models isn't currently at the point where maintainers are willing to merge them without human review, which takes approximately as much effort as writing the patches themselves. You can imagine the wailing and gnashing of teeth about "slop PRs" and "extractive contributions" that'd be all over HN.
eqvinox 12 hours ago [-]
Anthropic's oss-scanner includes patches. We've received a batch and I'm working on some of it.
A good amount of the patches is straight garbage. It's not helped by the fact that a good amount (20~30%, maybe more) of the issues is also junk themselves.
I'll hopefully be able to share numbers (or data) after we're done with the batch.
munchbunny 10 hours ago [-]
I won't claim that my experience is representative, but what I've seen is closer to 50% being false positives, and then maybe 20% of the remainder being bugs but not vulnerabilities (aka lower priority bugfixes). The suggested patches have a much worse hit rate though, to the extent that I accepted only a small fraction after reviewing.
That said, an automated system generating only 30% true positives is probably still ahead on ROI as long as we're talking about tens of findings and not hundreds. The amount of human time spent investigating things that turn out to be false positives being the main difference for how over or underwhelming it is.
eqvinox 2 hours ago [-]
Yeah, I was being "optimistic" in my estimate. And of course with a batch, you start at the high severity end, so it gets worse as you progress through. (Well, I assume at least, even some of the "critical" was just plain "not even a security issue" in our case.)
grim_io 11 hours ago [-]
70-80% not being garbage sounds like a good thing :)
eqvinox 2 hours ago [-]
You're assuming the other 70-80% is actually good. It's not, there's a whole spectrum between "junk" and "good". A whole bunch of this stuff is "technically correct, technically even a security issue, but also just plainly not of actual importance".
macintux 10 hours ago [-]
I suppose it depends on:
- How many patches you receive
- How easy it is/long it takes to distinguish the good from the garbage
matkoniecz 12 hours ago [-]
> If the concern is cost, Anthropic offers a Claude for OSS program.
thanks! It turns out that I am apparently qualifying for it and I was unaware
lets see whether Anthropic agrees
wonnage 13 hours ago [-]
Could also be that most of the findings are low signal noise. Even the batch that was sent to curl was one medium and 39 low severity. One can only assume that the vast numbers of findings that haven’t been sent are even lower severity.
grim_io 7 hours ago [-]
I'd be careful to take an examplary projects like curl and assume that level of quality is the average or even close to it.
Compared to curl, even the Linux kernel is garbage, and the Linux kernel is probably higher quality than all of the enterprise software that runs the world.
flanz_10 14 hours ago [-]
And on top of that, it's a bit negative. How many millions of dollars is one perfect-10 scoring CVSS finding, total destruction style RCE, found in curl worth? Considering how many people use it.
uptrails 13 hours ago [-]
It's worth zero millions dollars to curl. It might be worth something to attackers, but "wide use" is not the same as "the ability to compromise everyone" because most of the time, curl isn't used to automatically fetch untrusted URLs in a way that's controlled by the attacker from an environment they care about. It's worth much, much less than a 0-day in an iPhone or PHP. You'd need a buyer with a very specific itch to scratch and there won't be a bidding war.
By extension, if a vuln is worth something to attackers, it's probably also worth some fraction of it to their potential victims. But if you're an interesting target, your defense can't be based on the ability to find out about every single software defect ahead of the time. You need layers. And if you have that, the importance of proactively acquiring every 0-day is diminished.
pixl97 11 hours ago [-]
Your layers need to be secure too, or you just have colanders stacked together.
Eridrus 13 hours ago [-]
A client-side bug in a command line utility that is mostly used as a debugging tool or glue in shell scripts where the URL is not attacker controlled? Probably close to nothing. Maybe if you can find some other software which lets you run curl with an attacker controlled URL, you could package it up as an exploit for that piece of software, but it's not a common config.
palata 13 hours ago [-]
Curl is also a library. Just saying :-).
Eridrus 13 hours ago [-]
Fair, libcurl is pretty widely used in PHP, but it has to be in the core.
Still way less impactful than the PHP2Shell issue.
jonhohle 11 hours ago [-]
libcurl is used in a lot more than PHP. libcurl is installed on more than 20 billion devices.
jknoepfler 13 hours ago [-]
The most likely explanation is that it isn't worth submitting a massive stack of bullshit to human review.
If they actually were sitting on a PR gold mine of vulnerabilities they wouldn't be throttled on review resources while artificially inflating/misreporting their numbers. They would be diverting resources to clear the review queue.
It's fake and it always was fake.
sigmar 12 hours ago [-]
> 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.
But are these vulnerabilities actually useful to attackers?
I thought the idea is that they are finding them before they are used in the wild -- how would an unfound vulnerability be useful to an attacker?
SiempreViernes 7 hours ago [-]
This question is a rewording of "are these questions actually high impact?", and is being asked because Anthropic said almost everything they found was high impact.
oofbey 9 hours ago [-]
It’s almost as if the author thinks Glasswing should arming attackers with vulnerabilities.
delichon 14 hours ago [-]
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.
shiandow 14 hours ago [-]
So far the trend is pointing to AI being better at finding problems than designing software to avoid them.
Which I'm fine with really, but it means you need to be very careful letting it iterate on code until it finds no problems.
RugnirViking 13 hours ago [-]
If anyone here hasn't experienced agents going into a loop finding "problems" and "fixing" them by adding more brittle complexity which introduces 10 more problems I'd be surprised. It's like the biggest experience of working with agents RN
The worst part is being thorough takes so much more work - they often do raise valid problems but you just can't set them in a loop because of this tendancy so you end up with way more work and hard questions
canpan 13 hours ago [-]
It is my biggest problem now: AI is very good at adding things. It does not notice that things can be removed.
This is true for both code and prose. Even when it does notice something wrong, it wont remove it, but keep the sentence and make it longer.
"This is A" -> "This is B, not A"
It makes it incredibly hard to write plans and documents and maintain code.
When I tell it that the file is getting overlong and complex, unless I mention explicitly each single point, it just plainly doesn't see the problems and instead removes important bits. I did not yet find the right wording to express it to AI in an automated way.
radlad 13 hours ago [-]
I have a "review panel" skill, that will do multiple rounds. But after two rounds, it looks for hot spots. If hot spots are found, it triggers a "big picture" design review.
It's been helpful.
RugnirViking 13 hours ago [-]
yeah, thats similar to our current approach. It was inspired by a blog post from anthropic where they talked about the same kinda idea, where iirc after 3 rounds the author is asked to rearchitect.
The only other bit we also stole from that was the idea of only looking for issues in the original diff rather than spawning new problems from each diff fixing the previous. Of course the possibility exists of bugs being introduced while fixing others but we try to handle that with human review for the minute because its not worth getting agents to cover that bit, at least with naive approaches
senderista 13 hours ago [-]
So true, I had to learn this the hard way. I ended up doing a convergence review after each loop iteration and suggesting scope to cut where findings were diverging.
jack_pp 13 hours ago [-]
have you tried modularizing / breaking down your code into different files (ideally each having functional code so they don't depend much on anything else) as much as possible?
shiandow 4 hours ago [-]
I have. My main 'claim' is that AI isn't naturally inclined to structure code well.
Doesn't mean you can't make it, or rather you must.
wasabi991011 12 hours ago [-]
That's my biggest issue with it personally, as an academic. Way too much unnecessary indirection that makes it harder to read and understand the assumptions and parameters going into the code, and unnecessary defensive programming for code that is just going to be run a few different ways with strictly controlled inputs.
shiandow 4 hours ago [-]
I knew it. I keep asking people why they're constantly checking if an attribute might be empty.
One particularly bad instance consisted of someone checking for the existence of an attribute on a class they had created themselves.
When I asked why they didn't simply ensure the attribute existed they got defensive.
RugnirViking 13 hours ago [-]
are you suggesting this because you think I haven't tried it? I'm genuinely confused. We are professional developers working with a team of more than 1 person. Yes we have code in multiple files and have heard of the basic ideas of software architecture.
It's like being asked if i'm using source control? It's kinda a given if you're doing more than hobby projects.
jack_pp 13 hours ago [-]
I'm saying lean more into it, to the extreme and instruct your models to do the same
wasabi991011 12 hours ago [-]
How would that help with the raised issue?
jack_pp 12 hours ago [-]
Smaller the function, less ways to screw it up, for humans and llms alike. I suspect humans don't code like this because it is too tedious but LLMs don't have such problems
ASalazarMX 13 hours ago [-]
Coding is hard. I wouldn't be surprised if any patch they suggest came with new bugs, as it often happens with humans.
InsidiousWombat 11 hours ago [-]
once you have documented test for a bug AI is VERY good at fixing vulnerabilities. If there is a human there to look thru the fix code
gunalx 14 hours ago [-]
It'll never scew to far of as long as defence is a RL target. Better red team just means the blue team has stronger target environmenta to RL for.
a34729t 11 hours ago [-]
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.
kgeist 5 hours ago [-]
Last week I deployed GLM-5.3-Flash on our on-premise servers, ran it against all repos, and in 6 hours it found 13 vulnerabilities across our products/sites, including 1 full account takeover and an RCE on our site which involved a pretty sophisticated chain of __destruct gadgets (all vulns verified to work by a human).
As an experiment, I also pointed it at the PHP runtime's source code, and it was able to construct PHP code that triggered a use-after-free (or a segfault, if you prefer DoS). I failed to find the vulnerability in the list of CVEs, so maybe it's a 0day, I don't know.
Sure, it's not a frontier model, but it can find many issues that were overlooked by all the commercial security scanners we run regularly as well. The nice thing about this setup is that we can run it 24/7 probing our code/infra, constructing exploits, etc. without having to care about token usage/bills. Plus, I think sending all that sensitive information about your internal infrastructure and the vulns found to Anthropic is a vulnerability in itself.
hologramofham 14 hours ago [-]
> 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.
milkshakes 14 hours ago [-]
"public" here has nothing to do with government holding on to vulns. it's about landing fixes and coordinating complicated / impactful findings
Sharlin 12 hours ago [-]
You really think Anthropic would publish stats that say "Yeah, we've found 40k vulns but are going to keep 80% of them to ourselves [and the govt] because those are all the juicy ones"?
devy 11 hours ago [-]
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.
Pattern matching is a large part of the work. That's why LLM's have been so effective. A human can't match the speed of the loop, which is simple but very labor intensive.
arlattimore 12 hours ago [-]
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.
No, it's not, my question is how large the difference in quality is, as a result of the missing validation.
(I guess it's kinda impossible to know, we'd need Glasswing + oss-scanner comparison on the same project)
lhk931122 6 hours ago [-]
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.
greatgib 13 hours ago [-]
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.
Lerc 12 hours ago [-]
Which AGI claims are these specifically?
I find it hard to assess when people mention false claims when I can't find what the claims were to determine what about them might be false.
gregjw 9 hours ago [-]
Sankey diagrams are ruined for me
manlymuppet 10 hours ago [-]
Well in cases like these, it’s not the many that matter, but the few. Measuring in aggregate is not conclusive.
xyst 10 hours ago [-]
> 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.
jrflo 14 hours ago [-]
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.
fny 14 hours ago [-]
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.
tensor 12 hours ago [-]
I don't understand, it seems like every week there is a new major breach. Multiple law firms have had unprecedented breaches, dev platforms, and companies of every kind. You name it, there's been a high profile breach.
At the point I wonder if there is any information left secure honestly. These are not from glasswing, but they are from LLMs.
cowlevel 14 hours ago [-]
There was that PHP thing, as well as *sshole, and how do we know the supermarket attackers didn't use AI?
plorkyeran 12 hours ago [-]
While I'm not going to claim the PHP thing wasn't a real vulnerability, it... doesn't seem to have actually been catastrophically exploited? Maybe it's just too soon and over the next year we'll see a steady stream of people announcing leaks caused by failing to update php in time? Maybe there's a bunch of servers out there running old version of wordpress and quietly mining bitcoin because of it?
cowlevel 7 hours ago [-]
It wasn't exploited because half the internet shut down until it was fixed. Someone put up a site called "steal my bitcoin" with a vulnerable version of PHP and their bitcoin private key on the same server. It was hacked within two hours (of actually enabling PHP on the server) by someone with an AI agent.
But PHP thing was a lot of drama over something that was not super large easy to exploit hole. Just a normal "have to patch it and bye" medium kind issue.
spartanatreyu 13 hours ago [-]
> Just a normal "have to patch it and bye" medium kind issue.
Patching it was the issue, not the hole.
1. The patches had to be unofficially backported to the versions of php that most people were using.
2. Devs had to figure out if the unofficial backports were safe and they weren't just falling into trapped versions
3. Devs had to migrate all of their projects to unofficial versions
4. No one was ready for it to happen because there was no advance notice (someone broke the embargo) for everyone to plan maintenance windows and upgrade at the same time.
tptacek 13 hours ago [-]
People say this vulnerability was "not super large easy to exploit" because of one poorly-informed skeptical blog post that hit the top of HN, but the evidence strongly suggests that post was simply wrong, and we're just going to have to live with the misinformation until it decays.
At this point the play is simply to move the goalposts, suggesting that vulnerabilities don't matter so long as you yourself couldn't easily exploit them, regardless of what well-armed attackers can do with them. That's, obviously, not how software security works.
cowlevel 7 hours ago [-]
It's quite difficult to exploit. But so are most vulnerabilities, but attackers have figured out frameworks for exploiting hard vulnerabilities of this type. The proof is in the pudding - "steal my bitcoin" had its bitcoin stolen.
snowwrestler 13 hours ago [-]
Are there better sources for understanding the scope of impact enabled by PHP2Shell? My impression from a variety of sources is that very few incidents can be clearly attributed to that vulnerability. As opposed the many other ol’ ways PHP applications get exploited.
tialaramex 13 hours ago [-]
> the evidence strongly suggests that post was simply wrong
What sort of evidence? What "strongly suggests" this was actually easy to exploit?
tptacek 12 hours ago [-]
I'm not interested in arguing with you about whether e.g. Dan Guido is a credible source of exploitation information.
what 11 hours ago [-]
What a smug reply. Maybe you could just link to what Dan Guido has to say about it that supports your statement and why people should find that credible.
But, like, not wrong. I am kind of smug about this. People desperately wanted this bug not to be real. I don't pretend to know why. But it's clearly real.
cowlevel 7 hours ago [-]
The fact that "steal my bitcoin" got its bitcoin stolen within 2 hours?
grim_io 7 hours ago [-]
I think the post scan curl post did a lot of damage to the perception of real dangers.
Instead of highlighting the exceptional quality of curl, under intense, unprecedented scrutiny, the maintainer chose to dismiss Mythos as a nothingburger. I think this was a huge mistake and a disservice to curl itself.
watwut 5 hours ago [-]
The goalpost here was an apocalypse, thousands instantly hacked sites and hundreds of exploits flying around within hours. I did not made that goalpost. And reality did not hit that goalpost.
> vulnerabilities don't matter so long as you yourself couldn't easily exploit them, regardless of what well-armed attackers can do with them.
This is moving goalpost. The goalpost was not "yet another vulnerability like the others".
keybored 14 hours ago [-]
But imagine the potential fallout if so many services didn’t get so scared that they preemptively took themselves offline.
Apply sarcasm or not based on sleep deprivation.
Lerc 12 hours ago [-]
That seems like a damnned if you do and damnned if you don't situation.
There were conflicting claims about the degree to which the $6 Billion Binance heist was an AI thing. But either way it seems like it would be a "look what it enabled" or a look what it failed to prevent"
If nothing happens at all it's waved away as scaremongering rather than prevention.
qnleigh 13 hours ago [-]
Given how fast progress has been in the last year, be careful what you wish for...
For example, as others have noted, there were no results on cryptography in OpenAI's October 6th math drop. But it seems unlikely that they didn't look at this sort of thing.
stavros 14 hours ago [-]
We've had catastrophic vulnerabilities revealed every other day for months, what are you talking about?
TheCoelacanth 14 hours ago [-]
Vulnerabilities and exploits are different things.
stavros 14 hours ago [-]
You mean like Notion being breached, refrigerators being turned off, that kind of thing?
decidu0us9034 11 hours ago [-]
Industrial coolers and boilers and so forth being publicly exposed isn't a new thing though, people just used to avoid targeting civilian infrastructure in cyberwarfare... That's not like a new AI thing that's just human stupidity on display...
flanz_10 13 hours ago [-]
Those are exploits. They are different from vulnerabilities.
stavros 13 hours ago [-]
Yeah, I know, and we've had a deluge of both lately. I'm not sure what constructive point you're making.
12 hours ago [-]
beepbooptheory 13 hours ago [-]
You can have a lot of vulnerabilities without necessarily having working exploits to them, so it matters if it's just a lot of vulnerabilities without a lot of exploits.
sfink 12 hours ago [-]
Assume the original message said "exploits" in place of "vulnerabilities". The point stands, independent of pedantic terminology corrections.
The correction is valid. It would be better if people used the right term. It's ok to correct. But it would be better if it were in addition to discussion of the actual point, not instead of it.
(And the phrase "catastrophic vulnerabilities" is pretty obviously talking about exploits anyway.)
tensor 12 hours ago [-]
But we've had both. Soooo?
12 hours ago [-]
janalsncm 12 hours ago [-]
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.
The common thread is asking humans to do the verification work, which is the hard part.
pixl97 11 hours ago [-]
>most of which turned out to already exist
And if you came up with a model that discovered them without previous knowledge of them that's a pretty amazing tool. Huge numbers of materials are sat on by companies and little to nothing is published on them.
dcre 12 hours ago [-]
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.
ianmarcinkowski 9 hours ago [-]
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
nizbit 4 hours ago [-]
Thats cool I guess. Now do project Daybreak and compare the two. Also how does it stack against other cots solutions? Like the vibe from this article is I would have just as much luck if I used Nessus.
ddxv 1 hours ago [-]
Another Hacker News highly upvoted topic changing the title to mean something much different than what was upvoted.
The earlier title said something like most anthropic disclosed vulnerabilities were underwhelming (? Can't quite remember).
Also, everytime I notice this it's a change from negative AI sentiment to pro AI sentiment title! Haha
g-b-r 39 minutes ago [-]
The earlier title was the actual title of the article, "After 7-months, Glasswing Overwelms Maintainers with Underwhelming Findings"
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.
Expected this to happen maintainers overloaded with issues majority of which are nothing burgers.
resonious 11 hours ago [-]
And yet every single company is getting hacked. So some of the findings (presumably non-Glasswing) are clearly quite whelming!
rf15 1 hours ago [-]
Except... not that many companies are getting hacked. Not more than usual anyway, it feels like.
We don't see many significant big data leaks, or that many DDOS attacks.
elzbardico 9 hours ago [-]
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.
sick_of_slop 14 hours ago [-]
[dead]
unethical_ban 14 hours ago [-]
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.
tjmtjmtjm 13 hours ago [-]
Attribution/reporting is probably part of the conditions for these companies to get access.
epsteingpt 13 hours ago [-]
AI models generating slop findings? Who ever could have predicted this?!
Rendered at 13:12:28 GMT+0000 (Coordinated Universal Time) with Vercel.
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
If you told me that some significant number of Ant findings were duds, then I could reconcile that with what I saw first hand.
But TFA is making a more extreme statement
- Yeah, we could check the parameter here. Currently we don't return any result so let's add a success/failure response rather than silently failing.
- This is a highly unlikely situation, but let's harden it anyway in case things change and it bites us in the future.
I don't know how many end up in that situation, but it was a whole category of people claiming the LLM reviews are bad, that I haven't really considered before.
No matter how unlikely the issues seem to us, an LLM will happily chain dozens of them and do complex timing attacks to eventually gain access.
Useful to figure out if there are other cases like yours, so then commonalities can be inferred.
I’m just sharing my data point
For instance, it noticed that during CPU offlining, a page was freed and then something specific was written to it afterwards. Technically a use-after-free; but to exploit it you'd have to somehow know that the CPU was going to be offlined (not something that normally happens), then try to jigger the page to be allocated by someone such that the later write (also not controlled by you) actually did something you wanted.
Or, if you had a machine with over 5TiB of RAM, but for some reason your control plane was only assigned a single physical CPU, and then an attacker organized memory on boot a certain way, then it could crash the system.
The ones above ended up on the "not a security issue" side of the line, but a handful of ones ended up in the "is a security issue" side. These are all kind of excruciating, because on the one hand they seem so unlikely to even be able to trigger that they're hardly worth thinking about; but on the other hand who knows, maybe there are situations where it could happen.
NB these are just things Claude pointed out to me as I was working with the code, not things Anthropic reported.
> The slop is gone
> A sizeable portion of users seem to still believe we still suffer from a lot of made up and hallucinated reports by these AIs. We really don’t.
> Almost all the stupidity and lies we saw in the vulnerability reports made by AIs in the past have ceased. Since spring 2026 the slop reports are practically gone. Our current challenge is much harder: high volume, high quality.
https://daniel.haxx.se/blog/2026/10/22/ignore-the-slop/
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.
I would hypothesize that all the long-held "easily discovered if you look in the right place, but never reported and so never fixed" 0days in operating systems that criminal gangs and militaries have been relying on (to do cyberattacks with, unlock devices for forensic data recovery with, etc.), are increasingly being exposed and cleaned up, much faster than new such exploits can be discovered; and that this may have given an edge to whichever side of these conflicts don't rely so heavily on hacking the other to achieve their goals.
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
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.
A model with all the world's knowledge might know exactly how to weave them together into a successful exploit. And if tomorrow's models are even more capable, perhaps what we're experiencing now is just a fire drill for what's coming.
But they were all things that unambiguously violated the Fil-C promise
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.
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.
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.
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.
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
Probably curated
https://news.ycombinator.com/newsguidelines.html
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.
Agreed. My fairly obscure company got hit by something like this last weekend. What stood out was the speed: attackers found something small, used it to uncover something else, and pivoted to clever exploits for the new thing within minutes. It hit a dozen of our apps in parallel within the span of a day, from a rotating pool of residential proxies, Tor, GCP and Cloudflare IPs.
I'm fairly confident it was LLM-driven. The payloads and throwaway accounts had names like "PT59553 TEST IGNORE" and "PocCorp1659r2", and it adapted to error messages the way a person reading them would, just never sleeping. A non-tech company with 100x the surface area and much more valuable data could be in big trouble.
Of course I used LLMs for the defense too, and they were amazing at log forensics and fixes. The annoying part was when I asked Opus 5.5 for clear repro cases of exactly what the attackers did, I hit the cyber safeguards. Opus was trying to keep the exploits for my own bespoke applications away from me. It was happy to fix things of course, but I worry if it really can't 'think' about actual exploits, its fixes will be less informed.
billion dollar companies are not exempt from this, in fact they tend to be the worst offenders
https://www.controleng.com/throwback-attack-hackers-attempt-...
https://esemag.com/water/russian-hackers-breached-quebec-wat...
https://www.cbsnews.com/news/us-water-systems-cyberattacks-i...
https://www.bbc.com/news/world-us-canada-55989843
edit: formatting urls
Reminder that Stuxnet managed to jump an air gap (via USB keys):
* https://en.wikipedia.org/wiki/Stuxnet
Im still not worried about it. There's thousands of water treatment facilities in the USA and you've surfaced two occasions.
Ya'll should try actually breaking into something semi secure with an LLM, its not as easy as you might think. Seriously go try it, if you think its so easy there's millions of dollars to pick up off the floor on bugcrowd or h1. Seriously, please go give it a go.
Secondly, maybe the USA should stop committing mass murder across the globe if we don't want to be the subject of retaliatory attacks.
Do you think state actors are only capable of harming you now because of llms??? They don't need llms lol.
I would argue that systems were largely more vulnerable 5 years ago than they are now. Especially at a municiple level.
There seems to be a lot of "strategy of tension" being employed in these news cycles surrounding security and AI. Dont fall for it. You're fine. Systems are more secure now than they ever have been in the past.
But on the Israel note, thats awesome I hope more of that comes their way.
Airgaps don't solve everything either. Stuxnet was successful at destroying air-gapped machines.
I suspect open source projects are better off than proprietary software - they already have many eyes on them, whereas commercial software that’s not a prominent and profitable target (e.g. windows, ios) hasn’t had much attention until LLMs made attacking them significantly easier
Worse is everyone is like "Well, this stuff is protected or air gaped". Yea, it's behind firewall, or even private networks commonly, but the moment you get inside that network you have tons of lateral movement and could cause unbelievable damage in minutes.
This has been disproven by the sordid history of OpenSSL. It was open source, critical, and full of holes.
https://www.mend.io/blog/how-the-heartbleed-vulnerability-sh...
Afaik everyone working on curl has a day job.
They shouldn't. AI is great at some things and underwhelming at others, and it's never predictable if you're going to get the great response or the silly one and when you'll get it and over what topic. And you and the author combined are illustrating one scenario where that jaggedness shows up.
Make sure you’re still thinking.
Please avoid patronizing barbs in comments on HN. I can believe you didn't intend to be mean, but it's easy for these things to be misinterpreted on a text-only message board. https://news.ycombinator.com/newsguidelines.html
We've sure seen that LLMs can make good assumptions about blackboxes and, unlike humans, are able to try many paths in a short time. However, one can't neglect that doomsday prayers have been present before the dawn of AI, and rarely companies got hacked.
From anecdata, the human is still most often the culprit for breaches, not the "We managed to penetrate that one byte often enough" exploit.
Personally, I would be absolutely astonished if there were not numerous catastrophic security flaws in LOTS of private codebases in even the best engineering orgs. How discoverable are they without access to the code? Well - how many people have access to that code?
Beyond that, I'm confused. OP gives data supporting the idea that security concerns have been a puff-piece PR stunt. Glasswing's numbers are fake, and beyond that why on earth would a company not divert resources to processing vulnerabilities if they were sitting on a PR goldmine?
The response is "trust me bro, I've been working hard to fix stuff for a private company." Which doesn't tell us anything.
The OP gives us ample reason to believe that this commenter has been wasted their time on non-issues caused by LLM slop-reporting. This is consistent with my professional experience (and I'm confident resonates with the experience of many who actually work in the field).
The commenter theirself just says "trust me bro, private is different from public" which I do not have reason to believe.
I work for a private enterprise that has been deluged with security issues that we are fixing while adding zero value to the company due to corporate's response to "Mythos."
We are finding that almost none of these issues are valid.
I would love - LOVE - to hear some kind of valid, quantified, well-argued justification for the titanic shift of resources away from productivity and towards security.
I would love to look at actual data, or for you to make an actual argument, or for someone to make some actual sense on the cybersecurity doomsday front. I engage in good faith with good faith arguments. I have not heard any.
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.
There is. But it will only be reliable if every transitive dependency of your codebase, all the way down to the hardware level, has been formally verified. Failing that, you have to rely on opaque contracts at the boundaries, and those are just promises that may be mistaken.
The Halting problem, Rice's theorem, etc. only apply if your goal is to automatically and completely deduce properties or their violations for arbitrary programs. If your goal is simply to prove security and correctness properties for well-understood classes of programs in industry, then there are no fundamental obstructions.
If we want perfectly secure systems, then perhaps we don’t want universal and general purpose ones.
We cannot automatically and completely verify nontrivial semantic properties of arbitrary programs written in a Turing-complete language (Rice's theorem), but as long as we as humans can intuit correctness arguments for our programs, then formal methods will apply to it. Of course, declarative rather than imperative programming semantics tend to result in simpler correctness arguments, sidestepping reliance on global state and convoluted loop invariants.
Maybe the digital equivalent of being locked in a doomsday bunker eating only white rice doesn't produce interesting software experiences.
I imagine it would be a nightmare to work with.
That's consistent with my experience using them for coding, where even the best models mostly work by being persistently midwit (with infinite knowledge) more than individually brilliant.
One corollary of this is probably that any project that has had an army of actual monkeys pounding on it for years is likely more resistant to LLM attack than one that has not. Everyone is worrying about individual robot geniuses finding obscure vulnerabilities in Linux, PHP, Python, etc., but they should probably be more worried about the permutations of less-known software floating around their systems.
A computer that isn’t connected to anything (make sure to disable Bluetooth and the microphone) is already safe. I bet eventually we’ll be able to serve static HTML pages safely eventually. Maybe not images. Font selections might have to be pretty restricted. But, at least we’ll have the useful part of the internet back.
Just get rid of the computer at that point.
Well, the report you're replying to doesn't make me so hopeful: "7349 findings made public, 217 (.5%) fixed"
The used curl project as source which’s received mythos reports directly. What’s “tangential” about it?
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.
Of course it's trivial to have an LLM generate a fix, too. They probably do. It doesn't mean a project (1) wants to take an LLM-generated fix at all, or (2) can immediately commit an LLM-generated fix without review (which takes time).
But right now they’re not even offering one. They’re just putting the burden on the project without even trying to help fix it.
They have all the resources in the world, and they won’t even try.
And that’s of course assuming it’s a real bug, as we’ve seen a ton of them don’t seem to be. The last time we went through this, curl reported not only that a bunch of them weren’t bugs, but some of the bugs were listed previously on their mailing list, and that’s probably where the LLM got them.
So not only is it finding small bugs. And nonbugs. It’s reporting previously found bugs.
Pilling work on maintainers. Over and over again. To help? No. To make big numbers to show off for their IPO documents.
> They have all the resources in the world, and they won’t even try.
You sure about that?
https://news.ycombinator.com/item?id=50448558
The reason Anthropic isn't proactively sending patches is, I suspect, that those patches would not be welcomed, because trust in the models isn't currently at the point where maintainers are willing to merge them without human review, which takes approximately as much effort as writing the patches themselves. You can imagine the wailing and gnashing of teeth about "slop PRs" and "extractive contributions" that'd be all over HN.
A good amount of the patches is straight garbage. It's not helped by the fact that a good amount (20~30%, maybe more) of the issues is also junk themselves.
I'll hopefully be able to share numbers (or data) after we're done with the batch.
That said, an automated system generating only 30% true positives is probably still ahead on ROI as long as we're talking about tens of findings and not hundreds. The amount of human time spent investigating things that turn out to be false positives being the main difference for how over or underwhelming it is.
- How many patches you receive
- How easy it is/long it takes to distinguish the good from the garbage
thanks! It turns out that I am apparently qualifying for it and I was unaware
lets see whether Anthropic agrees
Compared to curl, even the Linux kernel is garbage, and the Linux kernel is probably higher quality than all of the enterprise software that runs the world.
By extension, if a vuln is worth something to attackers, it's probably also worth some fraction of it to their potential victims. But if you're an interesting target, your defense can't be based on the ability to find out about every single software defect ahead of the time. You need layers. And if you have that, the importance of proactively acquiring every 0-day is diminished.
Still way less impactful than the PHP2Shell issue.
If they actually were sitting on a PR gold mine of vulnerabilities they wouldn't be throttled on review resources while artificially inflating/misreporting their numbers. They would be diverting resources to clear the review queue.
It's fake and it always was fake.
> 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.
Which I'm fine with really, but it means you need to be very careful letting it iterate on code until it finds no problems.
The worst part is being thorough takes so much more work - they often do raise valid problems but you just can't set them in a loop because of this tendancy so you end up with way more work and hard questions
This is true for both code and prose. Even when it does notice something wrong, it wont remove it, but keep the sentence and make it longer.
"This is A" -> "This is B, not A"
It makes it incredibly hard to write plans and documents and maintain code.
When I tell it that the file is getting overlong and complex, unless I mention explicitly each single point, it just plainly doesn't see the problems and instead removes important bits. I did not yet find the right wording to express it to AI in an automated way.
It's been helpful.
The only other bit we also stole from that was the idea of only looking for issues in the original diff rather than spawning new problems from each diff fixing the previous. Of course the possibility exists of bugs being introduced while fixing others but we try to handle that with human review for the minute because its not worth getting agents to cover that bit, at least with naive approaches
Doesn't mean you can't make it, or rather you must.
One particularly bad instance consisted of someone checking for the existence of an attribute on a class they had created themselves.
When I asked why they didn't simply ensure the attribute existed they got defensive.
It's like being asked if i'm using source control? It's kinda a given if you're doing more than hobby projects.
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.
As an experiment, I also pointed it at the PHP runtime's source code, and it was able to construct PHP code that triggered a use-after-free (or a segfault, if you prefer DoS). I failed to find the vulnerability in the list of CVEs, so maybe it's a 0day, I don't know.
Sure, it's not a frontier model, but it can find many issues that were overlooked by all the commercial security scanners we run regularly as well. The nice thing about this setup is that we can run it 24/7 probing our code/infra, constructing exploits, etc. without having to care about token usage/bills. Plus, I think sending all that sensitive information about your internal infrastructure and the vulns found to Anthropic is a vulnerability in itself.
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.
[1] https://news.ycombinator.com/item?id=50342622
[2] https://news.ycombinator.com/item?id=49929391
(I guess it's kinda impossible to know, we'd need Glasswing + oss-scanner comparison on the same project)
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.
I find it hard to assess when people mention false claims when I can't find what the claims were to determine what about them might be false.
This is the entire premise of LLM hype wave. Or any overhyped tech that tries to force its way into every aspect of life.
> 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.
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.
At the point I wonder if there is any information left secure honestly. These are not from glasswing, but they are from LLMs.
https://stealmybitcoin.com/
Patching it was the issue, not the hole.
1. The patches had to be unofficially backported to the versions of php that most people were using.
2. Devs had to figure out if the unofficial backports were safe and they weren't just falling into trapped versions
3. Devs had to migrate all of their projects to unofficial versions
4. No one was ready for it to happen because there was no advance notice (someone broke the embargo) for everyone to plan maintenance windows and upgrade at the same time.
At this point the play is simply to move the goalposts, suggesting that vulnerabilities don't matter so long as you yourself couldn't easily exploit them, regardless of what well-armed attackers can do with them. That's, obviously, not how software security works.
What sort of evidence? What "strongly suggests" this was actually easy to exploit?
But, like, not wrong. I am kind of smug about this. People desperately wanted this bug not to be real. I don't pretend to know why. But it's clearly real.
Instead of highlighting the exceptional quality of curl, under intense, unprecedented scrutiny, the maintainer chose to dismiss Mythos as a nothingburger. I think this was a huge mistake and a disservice to curl itself.
> vulnerabilities don't matter so long as you yourself couldn't easily exploit them, regardless of what well-armed attackers can do with them.
This is moving goalpost. The goalpost was not "yet another vulnerability like the others".
Apply sarcasm or not based on sleep deprivation.
There were conflicting claims about the degree to which the $6 Billion Binance heist was an AI thing. But either way it seems like it would be a "look what it enabled" or a look what it failed to prevent"
If nothing happens at all it's waved away as scaremongering rather than prevention.
For example, as others have noted, there were no results on cryptography in OpenAI's October 6th math drop. But it seems unlikely that they didn't look at this sort of thing.
The correction is valid. It would be better if people used the right term. It's ok to correct. But it would be better if it were in addition to discussion of the actual point, not instead of it.
(And the phrase "catastrophic vulnerabilities" is pretty obviously talking about exploits anyway.)
https://pmc.ncbi.nlm.nih.gov/articles/PMC11044265/
The common thread is asking humans to do the verification work, which is the hard part.
And if you came up with a model that discovered them without previous knowledge of them that's a pretty amazing tool. Huge numbers of materials are sat on by companies and little to nothing is published on them.
> 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.
/Rant
The earlier title said something like most anthropic disclosed vulnerabilities were underwhelming (? Can't quite remember).
Also, everytime I notice this it's a change from negative AI sentiment to pro AI sentiment title! Haha
[0] <https://www.vulncheck.com/blog/anthropic-glasswing-november-...>
[1] <https://www.youtube.com/watch?v=NnV_cWeoo5Q>
no moat
We don't see many significant big data leaks, or that many DDOS attacks.