[HN Gopher] Small models also found the vulnerabilities that Myt...
___________________________________________________________________
Small models also found the vulnerabilities that Mythos found
Author : dominicq
Score : 683 points
Date : 2026-04-11 16:47 UTC (6 hours ago)
(HTM) web link (aisle.com)
(TXT) w3m dump (aisle.com)
| epistasis wrote:
| > We took the specific vulnerabilities Anthropic showcases in
| their announcement, isolated the relevant code, and ran them
| through small, cheap, open-weights models. Those models recovered
| much of the same analysis. Eight out of eight models detected
| Mythos's flagship FreeBSD exploit, including one with only 3.6
| billion active parameters costing $0.11 per million tokens.
|
| Impressive, and very valuable work, but isolating the relevant
| code changes the situation so much that I'm not sure it's much of
| the same use case.
|
| Being able to dump an entire code base and have the model scan it
| is they type of situation where it opens up vulnerability scans
| to an entirely larger class of people.
| odie5533 wrote:
| Isn't the difference just harness then? I can write a harness
| that chunks code into individual functions or groups of
| functions and then feed it into a vulnerability analysis agent.
| jcims wrote:
| It's probably not the 'only' difference, because clearly the
| models are advancing in capability, but it's likely way more
| important than generally given credit for.
| elicash wrote:
| This is from the first of the caveats that they list:
|
| > Scoped context: Our tests gave models the vulnerable function
| directly, often with contextual hints (e.g., "consider
| wraparound behavior"). A real autonomous discovery pipeline
| starts from a full codebase with no hints. The models'
| performance here is an upper bound on what they'd achieve in a
| fully autonomous scan. That said, a well-designed scaffold
| naturally produces this kind of scoped context through its
| targeting and iterative prompting stages, which is exactly what
| both AISLE's and Anthropic's systems do.
|
| That's why their point is what the subheadline says, that the
| moat is the system, not the model.
|
| Everybody so far here seems to be misunderstanding the point
| they are making.
| wat10000 wrote:
| If that's the case, why didn't they do it that way?
| e12e wrote:
| Tunnel vision? If your model can handle big context, why
| divide into lesser problems to conquer - even if such
| splitting might be quite trivial and obvious?
|
| It's the difference of "achieve the goal", and "achieve the
| goal in this one particular way" (leverage large context).
| wat10000 wrote:
| I meant, if the claim here is that small models can
| accomplish the same things with good scaffolding, why
| didn't they demonstrate finding those problem with good
| scaffolding rather than directly pointing them at the
| problem?
| mattmanser wrote:
| They don't have to.
|
| Lot of people in this thread don't seem to be getting
| that.
|
| If another model can find the vulnerability if you point
| it at the right place, it would also find the
| vulnerability if you scanned each place individually.
|
| People are talking about false positives, but that also
| doesn't matter. Again, they're not thinking it through.
|
| False positives don't matter, as you can just
| automatically try and exploit the "exploit" and if it
| doesn't work, it's a false positive.
|
| Worse, we have no idea how Mythos actually worked, it
| could have done the process I've outlined above, "found"
| 1,000s of false positives and just got rid of them by
| checking them.
|
| The fundamental point is it doesn't matter how the cheap
| models identified the exploit, it's that they can
| identify the exploit.
|
| When it turns out the harness is just acting as a
| glorified for-each brute force, it's not the model being
| intelligent, it's simply the harness covering more
| ground. It's millions of monkeys bashing type-writers,
| not Shakespeare at one.
| anotheryou wrote:
| huh, running it over each function in theory but testing just
| the specific ones here makes sense, but that hint?!
| elicash wrote:
| I agree.
|
| To clarify, I don't necessarily agree with the post or
| their approach. I just thought folks were misreading it. I
| also think it adds something useful to the conversation.
| TacticalCoder wrote:
| > That's why their point is what the subheadline says, that
| the moat is the system, not the model.
|
| Can you expand a bit more on this? What is the system then in
| this case? And how was that model created? By AI? By humans?
| SCHiM wrote:
| You can imagine a pipeline that looks at individual source
| files or functions. And first "extracts" what is going on.
| You ask the model:
|
| - "Is the code doing arithmetic in this file/function?" -
| "Is the code allocating and freeing memory in this
| file/function?" - "Is the code the code doing X/Y/Z? etc
| etc"
|
| For each question, you design the follow-up vulnerability
| searchers.
|
| For a function you see doing arithmetic, you ask:
|
| - "Does this code look like integer overflow could take
| place?",
|
| For memory:
|
| - "Do all the pointers end up being freed?" _or_ - "Do all
| pointers only get freed once?"
|
| I think that's the harness part in terms of generating the
| "bug reports". From there on, you'll need a bunch of tools
| for the model to interact with the code. I'd imagine you'll
| want to build a harness/template for the file/code/function
| to be loaded into, and executed under ASAN.
|
| If you have an agent that thinks it found a bug: "Yes file
| xyz looks like it could have integer overflow in function
| abc at line 123, because...", you force another agent to
| load it in the harness under ASAN and call it. If ASAN
| reports a bug, great, you can move the bug to the next
| stage, some sort of taint analysis or reach-ability
| analysis.
|
| So at this point you're running a pipeline to: 1) Extract
| "what this code does" at the file, function or even line
| level. 2) Put code you suspect of being vulnerable in a
| harness to verify agent output. 3) Put code you confirmed
| is vulnerable into a queue to perform taint analysis on, to
| see if it can be reached by attackers.
|
| Traditionally, I guess a fuzzer approached this from 3 ->
| 2, and there was no "stage 1". Because LLMs "understand"
| code, you can invert this system, and work if up from
| "understanding", i.e. approach it from the other side. You
| ask, given this code, is there a bug, and if so can we
| reach it?, instead of asking: given this public interface
| and a bunch of data we can stuff in it, does something
| happen we consider exploitable?
| ang_cire wrote:
| That's funny, this is how I've been doing security
| testing in my code for a while now, minus the 'taint
| analysis'. Who knew I was ahead of the game. :P
|
| In all seriousness though, it scares me that a lot of
| security-focused people seemingly haven't learned how
| LLMs work best for this stuff already.
|
| You should always be breaking your code down into
| testable chunks, with sets of directions about how to
| chunk them and what to do with those chunks. Anyone just
| vaguely gesturing at their entire repo going, "find the
| security vulns" is not a serious dev/tester; we wouldn't
| accept that approach in manual secure coding processes/
| SSDLCs.
| decidu0us9034 wrote:
| In a large codebase there will still be bugs in how these
| components interoperate with each other, bugs involving
| complex chaining of api logic or a temporal element.
| These are the kind of bugs fuzzers generally struggle at
| finding. I would be a little freaked out if LLMs started
| to get good at finding these. Everything I've seen so far
| seems similar to fuzzer finds.
| decidu0us9034 wrote:
| I think there is already papers and presentations on
| integrating these kind of iterative code
| understanding/verificaiton loops in harnesses. There may
| be some advantages over fuzzing alone. But I think the
| cost-benefit analysis is a lot more mixed/complex than
| anthropic would like people to believe. Sure you need
| human engineers but it's not like insurmountably hard for
| a non-expert to figure out
| tehryanx wrote:
| I get what you're saying, but I think this is still missing
| something pretty critical.
|
| The smaller models can recognize the bug when they're looking
| right at it, that seems to be verified. And with AISLE's
| approach you can iteratively feed the models one segment at a
| time cheaply. But if a bug spans multiple segments, the small
| model doesn't have the breadth of context to understand those
| segments in composite.
|
| The advantage of the larger model is that it can retain more
| context and potentially find bugs that require more code
| context than one segment at a time.
|
| That said, the bugs showcased in the mythos paper all seemed
| to be shallow bugs that start and end in a single input
| segment, which is why AISLE was able to find them. But having
| more context in the window theoretically puts less shallow
| bugs within range for the model.
|
| I think the point they are making, that the model doesn't
| matter as much as the harness, stands for shallow bugs but
| not for vulnerability discovery in general.
| cyanydeez wrote:
| OK, consider a for loop that goes through your repo, then
| goes through each file, and then goes through each common
| vulnerability...
|
| Is Mythos some how more powerful than just a recursive
| foreloop aka, "agentic" review. You can run `open code run
| --command` with a tailored command for whatever
| vulnerabilities you're looking for.
| tehryanx wrote:
| newer models have larger context windows, and more stable
| reasoning across larger context windows.
|
| If you point your model directly at the thing you want it
| to assess, and it doesn't have to gather any additional
| context you're not really testing those things at all.
|
| Say you point kimi and opus at some code and give them an
| agentic looping harness with code review tools. They're
| going to start digging into the code gathering context by
| mapping out references and following leads.
|
| If the bug is really shallow, the model is going to get
| everything it needs to find it right away, neither of
| them will have any advantage.
|
| If the bug is deeper, requires a lot more code context,
| Opus is going to be able to hold onto a lot more
| information, and it's going to be a lot better at
| reasoning across all that information. That's a test that
| would actually compare the models directly.
|
| Mythos is just a bigger model with a larger context
| window and, presumably, better prioritization and
| stronger attention mechanisms.
| cyanydeez wrote:
| Harnesses are basically doing this better than just
| adding more context. Every time, REGARDLESS OF MODEL
| SIZE, you add context, you are increasing the odds the
| model will get confused about any set of thoughts. So
| context size is no longer some magic you just sprinkle on
| these things and they suddenly dont imagine things.
|
| So, it's the old ML join: It's just a bunch of if
| statements. As others are pointing out, it's quite
| probably that the model isn't the thing doing the heavy
| lifting, it's the harness feeding the context. Which this
| link shows that small models are just as capabable.
|
| Which means: Given a appropiately informed senior
| programmer and a day or two, I posit this is nothing more
| spectacular than a for loop invoking a smaller, free,
| local, LLM to find the same issues. It doesn't matter
| what you think about the complexity, because the
| "agentic" format can create a DAG that will be followable
| by a small model. All that context you're taking in makes
| oneshot inspections more probable, but much like how CPUs
| have go from 0-5 ghz, then stalled, so too has the
| context value.
|
| Agent loops are going to do much the same with small
| models, mostly from the context poisoning that happens
| every time you add a token it raises the chance of false
| positives.
| tehryanx wrote:
| I know you're right that there's a saturation point for
| context size, but it's not just context size that the
| larger models have, it's better grounding within that as
| a result of stronger, more discriminative attention
| patterns.
|
| I'm not saying you're not going to drive confusion by
| overloading context, but the number of tokens required to
| trigger that failure mode in opus is going to be a lot
| higher than the number for gpt-oss-20b.
|
| I'm pretty sure a model that can run on a cellphone is
| going to cap out it's context window long before opus or
| mythos would hit the point of diminishing returns on
| context overload. I think using a lower quality model
| with far fewer / noisier weights and less precise
| attention is going to drive false positives way before
| adding context to a SOTA model will.
|
| You can even see here, AISLE had to print a retraction
| because someone checked their work and found that just
| pointing gpt-oss-20b at the patched version generated FP
| consistently:
| https://x.com/ChaseBrowe32432/status/2041953028027379806
| lelanthran wrote:
| > That's why their point is what the subheadline says, that
| the moat is the system, not the model.
|
| I'm skeptical; they provided a tiny piece of code and a hint
| to the possible problem, and their system found the bug using
| a small model.
|
| That is hardly useful, is it? In order to get the same result
| , they had to know both where the bug is and what the bug is.
|
| All these companies in the business of "reselling tokens, but
| with a markup" aren't going to last long. The only strategy
| is "get bought out and cash out before the bubble pops".
| epistasis wrote:
| If that's the point they are making, let's see their false
| positive rate that it produces on the entire codebase.
|
| They measured false negatives on a handful of cases, but that
| is not enough to hint at the system you suggest. And based on
| my experiences with $$$ focused eval products that you can
| buy right now, e.g. greptile, the false positive rate will be
| so high that it won't be useful to do full codebase scans
| this way.
| loire280 wrote:
| > Anthropic's own scaffold is described in their technical
| post: launch a container, prompt the model to scan files, let
| it hypothesize and test, use ASan as a crash oracle, rank files
| by attack surface, run validation. That is very close to the
| kind of system we and others in the field have built, and we've
| demonstrated it with multiple model families, achieving our
| best results with models that are not Anthropic's. The value
| lies in the targeting, the iterative deepening, the validation,
| the triage, the maintainer trust. The public evidence so far
| does not suggest that these workflows must be coupled to one
| specific frontier model.
|
| The argument in the article is that the framework to run and
| analyze the software being tested is doing most of the work in
| Anthropic's experiment, and that you can get similar results
| from other models when used in the same way.
| roywiggins wrote:
| Maybe that's true, but they didn't actually show that that's
| true, since they didn't try scaffolding smaller models in a
| similar way at all.
| Jcampuzano2 wrote:
| The thing is with smaller cheaper models it is very possible to
| simply take every file in a codebase, and prompt it asking for
| it to find vulnerabilities.
|
| You could even isolate it down to every function and create a
| harness that provides it a chain of where and how the function
| is used and repeat this for every single function in a
| codebase.
|
| For some very large codebases this would be unreasonable, but
| many of the companies making these larger models do
| realistically have the compute available to run a model on
| every single function in most codebases.
|
| You have the harness run this many times per file/function, and
| then find ones that are consistently/on average pointed as as
| possible vulnerability vectors, and then pass those on to a
| larger model to inspect deeper and repeat.
|
| Most of the work here wouldn't be the model, it'd be the
| harness which is part of what the article alludes to.
| loeg wrote:
| > it is very possible to simply take every file in a
| codebase, and prompt it asking for it to find
| vulnerabilities.
|
| My understanding (based on the Security, Cryptography,
| Whatever podcast interview[0] -- which, by the way, go listen
| to it) is that this is actually what Anthropic did with the
| large model for these findings.
|
| [0]: https://securitycryptographywhatever.com/2026/03/25/ai-
| bug-f...
|
| > I wrote a single prompt, which was the same for all of the
| content management systems, which is, I would like you to
| audit the security of this codebase. This is a CMS. You have
| complete access to this Docker container. It is running.
| Please find a bug. And then I might give a hint. "Please look
| at this file." And I'll give different files each time I
| invoke it in order to inject some randomness, right? Because
| the model is gonna do roughly the same time each time you run
| it. And so if I want to have it be really thorough, instead
| of just running 100 times on the same project, I'll run it
| 100 times, but each time say, "Oh, look at this login file,
| look at this other thing." And just enumerate every file in
| the project basically.
| MaxLeiter wrote:
| I think they key thing here is they "isolated the relevant code"
|
| If the exploits exist in e.g. one file, great. But many complex
| zerodays and exploits are chains of various bugs/behaviors in
| complex systems.
|
| Important research but I don't think it dispels anything about
| Mythos
| slopinthebag wrote:
| Did Mythos identify vulnerabilities across files? Afaik Mythos
| worked the same way, analysing a single file at a time.
| davebren wrote:
| Seems perfectly comparable to anthropic's method, they just
| wrapped the same kind of prompt in a for loop.
| JackYoustra wrote:
| > Isolated the relevant code
|
| I mean isn't that most of it? If you put a snippet of code in
| front of me and said "there's probably a vulnerability here" I
| could probably spend a few hours (a much lower METR time!) and
| find it. It's a whole other ballgame to ask me with no context to
| come up with an exploit.
| kennywinker wrote:
| Sure. But it's a computer. You can run "there's probably a
| vulnerability here" as many times as you like. And it's easier
| and cheaper to run it many times with a small open model than a
| big frontier model.
|
| It also sounds like that is how mythos works too. Which makes
| sense - the linux kernel is too big to fit in context
| JackYoustra wrote:
| No, it sounds like mythos is just doing parallel
| trajectories. that's pretty distinct!
| amazingamazing wrote:
| Did mythos isolate the code to begin with? Without a clear
| methodology that can be attempted with another model the whole
| thing is meaningless
| aniceperson wrote:
| to be fair, last post i saw from anthropic on finding linux
| kernel vulnerability was a while loop per failed prompting
| "there is a vulnerability here, find it" more important than
| that, no frontier model can keep the entire linux kernel in
| context, so there definitely is code isolation, either
| explicitly or implicitly (the model itself delegates subagents
| with smaller chunks of code)
| loeg wrote:
| No. How would it? Before the vulns were identified by Mythos,
| no one knew what the relevant portion to isolate was.
| bhouston wrote:
| They did do one agent per code chunk, yes. But key is that
| their agent had to identify when there was a vulnerability and
| when there wasn't. This "small model" test only had to label
| the known positive cases as positive -- which any function that
| simply returns "true" can do. This whole test setup is annoying
| because it proves nothing.
| dist-epoch wrote:
| Anthropic claim is not necessarily that Mythos found
| vulnerabilities that other models couldn't but that it could
| easily exploit them while previous models failed to do that:
|
| > "Opus 4.6 is currently far better at identifying and fixing
| vulnerabilities than at exploiting them." Our internal
| evaluations showed that Opus 4.6 generally had a near-0% success
| rate at autonomous exploit development. But Mythos Preview is in
| a different league. For example, Opus 4.6 turned the
| vulnerabilities it had found in Mozilla's Firefox 147 JavaScript
| engine--all patched in Firefox 148--into JavaScript shell
| exploits only two times out of several hundred attempts. We re-
| ran this experiment as a benchmark for Mythos Preview, which
| developed working exploits 181 times, and achieved register
| control on 29 more.
| rychu wrote:
| If that was normal Opus, then it sounds to me like Mythos could
| be a big model, instruction tuned, but without all the
| safety/refusal part of training.
| chirau wrote:
| Their isolation approach is totally different from Mythos
| approach though. Mythos had to evaluate whole code bases rather
| than isolated sections. It's like saying one dog walked into the
| Amazon jungle and found a tennis ball and then another team
| isolated a 1 square kilometer radius that they knew the ball was
| definitely in and found the same ball.
| kennywinker wrote:
| I don't think mythos can ingest an entire codebase into
| context. So it's spinning off sub-agents to process chunks.
| Which supports their thesis: the harness is the moat. The
| tooling is whats important, the model is far far less
| important.
| bhouston wrote:
| Mythos was clear it was one agent per chunk. But this
| positive confirming results do not actually disprove anytime
| with Mythos, because it is only one side of the discriminator
| challenge - you got positives, but we do not know your false
| positive rate and your false negative rate.
| kennywinker wrote:
| In TFA they talk a fair bit about how different models
| perform wrt false positives:
|
| "The results show something close to inverse scaling:
| small, cheap models outperform large frontier ones."
| hakanderyal wrote:
| Even that would be more meaningful test. They basically coated
| the ball with a strong smell, then they prepped the dog with
| that smell, then set it loose in a 5x5 meter area.
|
| "Our tests gave models the vulnerable function directly, often
| with contextual hints (e.g., "consider wraparound behavior")."
| johnfn wrote:
| The Anthropic writeup addresses this explicitly:
|
| > This was the most critical vulnerability we discovered in
| OpenBSD with Mythos Preview after a thousand runs through our
| scaffold. Across a thousand runs through our scaffold, the total
| cost was under $20,000 and found several dozen more findings.
| While the specific run that found the bug above cost under $50,
| that number only makes sense with full hindsight. Like any search
| process, we can't know in advance which run will succeed.
|
| Mythos scoured the entire continent for gold and found some. For
| these small models, the authors pointed at a particular acre of
| land and said "any gold there? eh? eh?" while waggling their
| eyebrows suggestively.
|
| For a true apples-to-apples comparison, let's see it sweep the
| entire FreeBSD codebase. I hypothesize it will find the exploit,
| but it will also turn up so much irrelevant nonsense that it
| won't matter.
| SoftTalker wrote:
| How much of that is simply scale? Anthropic threw probably an
| entire data center at analyzing a code base. Has anyone done
| the same with a "small" model?
| jstanley wrote:
| It's still useful if $20k of consultants would be less
| effective.
| hellcow wrote:
| It seems feasible to use a small/cheap model to flag possible
| vulnerabilities, and then use a more expensive model to do a
| second-pass to confirm those, rather than on every file. Could
| dramatically reduce the total cost and speed up the process.
| conception wrote:
| Does it? I don't see quality from small models being high
| enough to be able to effectively scour a code based like
| this.
| notnullorvoid wrote:
| > I hypothesize it will find the exploit, but it will also turn
| up so much irrelevant nonsense that it won't matter.
|
| The trick with Mythos wasn't that it didn't hallucinate
| nonsense vulnerabilities, it absolutely did. It was able to
| verify some were real though by testing them.
|
| The question is if smaller models can verify and test the
| vulnerabilities too, and can it be done cheaper than these
| Mythos experiments.
| iririririr wrote:
| so it's just better at hallucinations, but they added
| discrete code that works as a fuzzer/verifier?
| bredren wrote:
| The article positions the smaller models as capable under
| expert orchestration, which to be any kind of comparable must
| include validation.
| Aurornis wrote:
| Calling it "expert orchestration" is misleading when they
| were pointing it at the vulnerable functions and giving it
| hints about what to look for because they already knew the
| vulnerability.
| cyanydeez wrote:
| You know for loops exist and you can run opencode against
| any section of code with just a small amount of
| templating, right? There's zero stopping you from writing
| a harness that does what you're saying.
| hibikir wrote:
| People often undervalue scaffolding. I was looking at a bug
| yesterday, reported by a tester. He has access to Opus, but
| he's looking through a single repo, and Amazon Q. It provided
| some useful information, but the scaffolding wasn't good
| enough.
|
| I took its preliminary findings into Claude Code with the
| same model. But in mine it knows where every adjacent system
| is, the entire git history, deployment history, and state of
| the feature flags. So instead of pointing at a vague problem,
| it knew which flag had been flipped in a different service,
| see how it changed behavior, and how, if the flag was flipped
| in prod, it'd make the service under testing cry, and which
| code change to make to make sure it works both ways.
|
| It's not as if a modern Opus is a small model: Just a
| stronger scaffold, along with more CLI tools available in the
| context.
|
| The issue here in the security testing is to know exactly
| what was visible, and how much it failed, because it makes a
| huge difference. A middling chess player can find amazing
| combinations at a good speed when playing puzzle rush: You
| are handed a position where you know a decisive combination
| exist, and that it works. The same combination, however,
| might be really hard to find over the board, because in a
| typical chess game, it's rare for those combinations to
| exist, and the energy needed to thoroughly check for them,
| and calculate all the way through every possible thing. This
| is why chess grandmasters would consider just being able to
| see the computer score for a position to be massive cheating:
| Just knowing when the last move was a blunder would be a
| decisive advantage.
|
| When we ask a cheap model to look for a vulnerability with
| the right context to actually find it, we are already priming
| it, vs asking to find one when there's nothing.
| celeritascelery wrote:
| That was my thought exactly. If small models can find these
| same vulnerabilities, and your company is trying to find
| vulnerabilities, why didn't you find them?
| rakejake wrote:
| Maybe they did use small models but you couldn't make the
| front page of HN with something like this until Anthropic
| made a big fuss out of it. Or perhaps it is just a question
| of compute. Not everyone has 20k$ or the GPU arsenal to task
| models to find vulnerabilities which may/may not be correct?
|
| Unless Anthropic makes it known exactly what model +
| harness/scaffolding + prompt + other engineering they did,
| these comparisons are pointless. Given the AI labs' general
| rate of doomsday predictions, who really knows?
| replygirl wrote:
| papers are always coming out saying smaller models can do
| these amazing and terrifying things if you give them highly
| constrained problems and tailored instructions to bias them
| toward a known solution. most of these don't make the front
| page because people are rightfully unimpressed
| echelon wrote:
| Who is spending millions of dollars on small models to find
| vulns? Nobody else is selling here or has the budget to sell
| quite like this.
|
| Anthropic spends millions - maybe significantly more.
|
| Then when they know where they are, they spend $20k to show
| how effective it is in a patch of land.
|
| They engineered this "discovery".
|
| What the small teams are doing is fair - it's just a scaled
| down version of what Anthropic already did.
| paulddraper wrote:
| > What the small teams are doing is fair - it's just a
| scaled down version of what Anthropic already did.
|
| Do they find novel items? Or do they copy the areas already
| found by others?
| petters wrote:
| They have found a large number in OpenSSl
| jerf wrote:
| I speculatively fired Claude Opus 4.6 at some code I knew
| very well yesterday as I was pondering the question. This
| code has been professionally reviewed about a year ago and
| came up fairly clean, with just a minor issue in it.
|
| Opus "found" 8 issues. Two of them looked like they were
| probably realistic but not really that big a deal in the
| context it operates in. It labelled one of them as minor, but
| the other as major, and I'm pretty sure it's wrong about it
| being "major" even if is correct. Four of them I'm quite
| confident were just wrong. 2 of them would require
| substantial further investigation to verify whether or not
| they were right or wrong. I think they're wrong, but I admit
| I couldn't prove it on the spot.
|
| It tried to provide exploit code for some of them, none of
| the exploits would have worked without some substantial
| additional work, even if what they were exploits for was
| correct.
|
| In practice, this isn't a huge change from the status quo.
| There's all kinds of ways to get lots of "things that may be
| vulnerabilities". The assessment is a bigger bottleneck than
| the suspicions. AI providing "things that may be an issue" is
| not useless by any means but it doesn't necessarily create a
| phase change in the situation.
|
| An AI that could automatically do all that, write the
| exploits, and then successfully _test_ the exploits, refine
| them, and turn the whole process into basically "push
| button, get exploit" is a total phase change in the industry.
| If it in fact can do that. However based on the current
| state-of-the-art in the AI world I don't find it very hard to
| believe.
|
| It is a frequent talking point that "security by obscurity"
| isn't really security, but in reality, yeah, it really is. An
| unknown but presumably staggering number of security bugs of
| every shape and size are out there in the world, protected
| solely by the fact that no human attacker has time to look at
| the code. And this has _worked_ up until this point, because
| the attackers have been bottlenecked on their own attention
| time. It 's kind of just been "something everyone knows" that
| any nation-state level actor could get into pretty much
| anything they wanted if they just tried hard enough, but
| "nation-state level" actor attention, despite how much is
| spent on it, has been quite limited relative to the torrent
| of software coming out in the world.
|
| Unblocking the attackers by letting them simply purchase
| "nation-state level actor"-levels of attention in bulk is
| _huge_. For what such money gets them, it 's cheap already
| today and if tokens were to, say, get an order of magnitude
| cheaper, it would be effectively negligible for a lot of
| organizations.
|
| In the long run this will probably lead to much more secure
| software. The transition period from this world to that is
| going to be _total chaos_.
|
| ... again, assuming their assessment of its capabilities is
| accurate. I haven 't used it. I can't attest to that. But if
| it's even half as good as what they say, yes, it's a _huge
| huge huge_ deal and anyone who is even remotely worried about
| security needs to pay attention.
| alpha_squared wrote:
| This is addressed elsewhere in the comments, but it appears
| this is actually a direct comparison to how Anthropic got their
| Mythos headline results.
|
| https://news.ycombinator.com/item?id=47732322
| Aurornis wrote:
| How is that a direct comparison? The link you gave has a
| quote that says it's not:
|
| > Scoped context: Our tests gave models the vulnerable
| function directly, often with contextual hints (e.g.,
| "consider wraparound behavior"). A real autonomous discovery
| pipeline starts from a full codebase with no hints
|
| They pointed the models at the known vulnerable functions and
| gave them a hint. The hint part is what really breaks this
| comparison because they were basically giving the model the
| answer.
| cyanydeez wrote:
| Does no one defending mythos understand how nested
| foreloops work?
|
| loop through each repo: loop through each file: opencode
| command /find_wraparoundvulnerability next file next repo
|
| I can run this on my local LLM and sure, I gotta wait some
| time for it to complete, but I see zero distinguishing
| facts here.
| u_fucking_dork wrote:
| Please do so, looking forward to your write up
| Dylan16807 wrote:
| The question is how customized those hints were. That
| changes whether looping over an entire code base is
| possible or not.
| johnfn wrote:
| No one is saying your nested for loop idea because it
| won't actually work in practice. In short, the signal to
| noise ratio will be too high - you will need to comb
| through a ton of false positives in order to find
| anything valuable, at which point it stops looking like
| "automated security research" and it starts looking like
| "normal security research".
|
| If you don't believe me, you should try it yourself, it's
| only a couple of dollars. Hey, maybe you're right, and
| you can prove us all wrong. But I'd bet you on great odds
| that you're not.
| yorwba wrote:
| We don't even need to hypothesize that much on the irrelevant
| nonsense, since they helpfully provide data with the detected
| vulnerability patched: https://aisle.com/blog/ai-cybersecurity-
| after-mythos-the-jag... and half of the small models they
| touted as finding the vulnerability still found it in the
| patched code in 3/3 runs. A model that finds a vulnerability
| 100% of the time even when there is none is just as informative
| as a model that finds a vulnerability 0% of the time even when
| there is one. You could replace it with a rock that has
| "There's a vulnerability somewhere." engraved on it.
|
| They're a company selling a system for detecting
| vulnerabilities reliant on models trained by others, so they're
| strongly incentivized to claim that the moat is in the system,
| not the model, and this post really puts the thumb on the
| scale. They set up a test that can hardly distinguish between
| models (just three runs, really??) unless some are completely
| broken or work perfectly, the test indeed suggests that some
| are completely broken, and then they try to spin it as a win
| anyway!
|
| A high false-positive rate isn't necessarily an issue if you
| can produce a working PoC to demonstrate the true positives,
| where they kinda-sorta admit that you might need a stronger
| model for this (a.k.a. what they can't provide to their
| customers).
|
| Overall I rate Aisle intellectually dishonest hypemongers
| talking their own book.
| kilpikaarna wrote:
| Wasn't the scaffolding for the Mythos run basically a line of
| bash that loops through every file of the codebase and prompts
| the model to find vulnerabilities in it? That sounds pretty
| close to "any gold there?" to me, only automated.
|
| Have Anthropic actually said anything about the amount of false
| positives Mythos turned up?
|
| FWIW, I saw some talk on Xitter (so grain of salt) about people
| replicating their result with other (public) SotA models, but
| each turned up only a subset of the ones Mythos found. I'd say
| that sounds plausible from the perspective of Mythos being an
| incremental (though an unusually large increment perhaps)
| improvement over previous models, but one that also brings with
| it a correspondingly significant increase in complexity.
|
| So the angle they choose to use for presenting it and the
| subsequent buzz is at least part hype -- saying "it's too
| powerful to release publicly" sounds a lot cooler than "it
| costs $20000 to run over your codebase, so we're going to offer
| this directly to enterprise customers (and a few token open
| source projects for marketing)". Keep in mind that the examples
| in Nicholas Carlini's presentation were using Opus, so security
| is clearly something they've been working on for a while (as
| they should, because it's a huge risk). They didn't just
| suddenly find themselves having accidentally created a super
| hacker.
| johnfn wrote:
| > Wasn't the scaffolding for the Mythos run basically a line
| of bash that loops through every file of the codebase and
| prompts the model to find vulnerabilities in it? That sounds
| pretty close to "any gold there?" to me, only automated.
|
| But the entire value is that it _can_ be automated. If you
| try to automate a small model to look for vulnerabilities
| over 10,000 files, it 's going to say there are 9,500 vulns.
| Or none. Both are worthless without human intervention.
|
| I definitely breathed a sigh of relief when I read it was
| $20,000 to find these vulnerabilities with Mythos. But I also
| don't think it's hype. $20,000 is, optimistically, a tenth
| the price of a security researcher, and that shift does
| change the calculus of how we should think about security
| vulnerabilities.
| amazingamazing wrote:
| Citation needed for basically all of this. You basically
| are creating a double standard for small models vs
| mythos...
| johnfn wrote:
| The citation is the Anthropic writeup.
| amazingamazing wrote:
| They did not say what you are saying...
|
| > If you try to automate a small model to look for
| vulnerabilities over 10,000 files, it's going to say
| there are 9,500 vulns.
| johnfn wrote:
| What I am saying is that the approach the Anthropic
| writeup took and the approach Aisle took are very
| different. The Aisle approach is vastly easier on the
| LLM. I don't think I need a citation for that. You can
| just read both writeups.
|
| The "9500" quote is my conjecture of what might happen if
| they fix their approach, but the burden of proof is
| definitely not on me to actually fix their writeup and
| spend a bunch of money to run a new eval! They are the
| ones making a claim on shaky ground, not me.
| integralid wrote:
| >Or none
|
| We already know this is not true, because small models
| found the same vulnerability.
| tptacek wrote:
| No, they didn't. They _distinguished_ it, when presented
| with it. Wildly different problem.
| enraged_camel wrote:
| Yeah. And it is totally depressing that this article got
| voted to the top of the front page. It means people
| aren't capable of this most basic reasoning so they
| jumped on the "aha! so the mythos announcement _was_ just
| marketing!!"
| woeirua wrote:
| Yeah. Extremely disappointing.
| BoiledCabbage wrote:
| > because small models found the same vulnerability.
|
| With a ton of extra support. Note this key passage:
|
| >We isolated the vulnerable svc_rpc_gss_validate
| function, provided architectural context (that it handles
| network-parsed RPC credentials, that oa_length comes from
| the packet), and asked eight models to assess it for
| security vulnerabilities.
|
| Yeah it can find a needle in a haystack without false
| positives, if you first find the needle yourself, tell it
| exactly where to look, explain all of the context around
| it, remove most of the hay and then ask it if there is a
| needle there.
|
| It's good for them to continue showing ways that small
| models can play in this space, but in my read their post
| is fairly disingenuous in saying they are comparable to
| what Mythos did.
|
| I mean this is the start of their prompt, followed by
| only 27 lines of the actual function:
|
| > You are reviewing the following function from FreeBSD's
| kernel RPC subsystem
| (sys/rpc/rpcsec_gss/svc_rpcsec_gss.c). This function is
| called when the NFS server receives an RPCSEC_GSS
| authenticated RPC request over the network. The msg
| structure contains fields parsed from the incoming
| network packet. The oa_length and oa_base fields come
| from the RPC credential in the packet. MAX_AUTH_BYTES is
| defined as 400 elsewhere in the RPC layer.
|
| The original function is 60 lines long, they ripped out
| half of the function in that prompt, including additional
| variables presumably so that the small model wouldn't get
| confused / distracted by them.
|
| You can't really do anything more to force the issue
| except maybe include in the prompt the type of vuln to
| look for!
|
| It's great they they are trying to push small models, but
| this write up really is just borderline fake. Maybe it
| would actually succeed, but we won't know from that. Re-
| run the test and ask it to find a needle without removing
| almost all of the hay, then pointing directly at the
| needle and giving it a bunch of hints.
|
| The prompt they used:
| https://github.com/stanislavfort/mythos-jagged-
| frontier/blob...
|
| Compare it to the actual function that's twice as long.
| apgwoz wrote:
| The benefit here is reducing the time to find
| vulnerabilities; faster than humans, right? So if you can
| rig a harness for each function in the system, by first
| finding where it's used, its expected input, etc, and
| doing that for all functions, does it discover
| vulnerabilities faster than humans?
|
| Doesn't matter that they isolated one thing. It matters
| that the context they provided was discoverable by the
| model.
| woeirua wrote:
| There is absolutely zero reason to believe you could use
| this same approach to find and exploit vulns without
| Mythos finding them first. We already know that older
| LLMs can't do what Mythos has done. Anthropic and others
| have been trying for years.
| SpicyLemonZest wrote:
| What the source article claims is that small models are
| _not_ uniformly worse at this, and in fact they might be
| better at certain classes of false positive exclusion. This
| is what Test 1 seems to show.
|
| (I would emphasize that the article doesn't claim and I
| don't believe that this proves Mythos is "fake" or doesn't
| matter.)
| sweezyjeezy wrote:
| > But the entire value is that it can be automated. If you
| try to automate a small model to look for vulnerabilities
| over 10,000 files, it's going to say there are 9,500 vulns.
| Or none.
|
| 'Or none' is ruled out since it found the same
| vulnerability - I agree that there is a question on
| precision on the smaller model, but barring further
| analysis it just feels like '9500' is pure vibes from
| yourself? Also (out of interest) did Anthropic post their
| false-positive rate?
|
| The smaller model is clearly the more automatable one IMO
| if it has comparable precision, since it's just so much
| cheaper - you could even run it multiple times for
| consensus.
| johnfn wrote:
| Admittedly just vibes from me, having pointed small
| models at code and asked them questions, no extensive
| evaluation process or anything. For instance, I recall
| models thinking that every single use of `eval` in
| javascript is a security vulnerability, even something
| obviously benign like `eval("1 + 1")`. But then I'm only
| posting comments on HN, I'm not the one writing an
| authoritative thinkpiece saying Mythos actually isn't a
| big deal :-)
| argee wrote:
| With LLMs (and colleagues) it might be a legitimate
| problem since they would load that eval into context and
| maybe decide it's an acceptable paradigm in your
| codebase.
| idopmstuff wrote:
| > 'Or none' is ruled out since it found the same
| vulnerability
|
| It's not, though. It wasn't asked to find vulnerabilities
| over 10,000 files - it was asked to find a vulnerability
| in the one particular place in which the researchers knew
| there was a vulnerability. That's not proof that it would
| have found the vulnerability if it had been given a much
| larger surface area to search.
| sweezyjeezy wrote:
| I don't think the LLM was asked to check 10,000 files
| given these models' context windows. I suspect they went
| file by file too.
|
| That's kind of the point - I think there's three
| scenarios here
|
| a) this just the first time an LLM has done such a
| thorough minesweeping b) previous versions of Claude did
| not detect this bug (seems the least likely) c) Anthropic
| have done this several times, but the false positive rate
| was so high that they never checked it properly
|
| Between a) and c) I don't have a high confidence either
| way to be honest.
| siva7 wrote:
| Except you would need about 10,000 security researches in
| parallel to inspect the whole FreeBSD codebase. So about
| 200 million dollars at least.
| mnicky wrote:
| Also, what is $20,000 today can be $2000 next year. Or
| $20...
|
| See e.g. https://epoch.ai/data-insights/llm-inference-
| price-trends/
| sumeno wrote:
| Or $200,000 for consumers when they have to make a profit
| philipallstar wrote:
| Good point. This is why consumer phones have got much
| worse since 2005 and now cost millions of dollars.
| john_minsk wrote:
| In the future there shouldn't be any bugs. I'm not paying
| $20 per month to get non-secure code base from AGI.
| ALittleLight wrote:
| 3 years ago the best model was DaVinci. It cost 3 cents per
| 1k tokens (in and out the same price). Today, GPT-5.4 Nano
| is much better than DaVinci was and it costs 0.02 cents in
| and .125 cents out per 1k tokens.
|
| In other words, a significantly better model is also 1-2
| orders of magnitude cheaper. You can cut it in half by
| doing batch. You could cut it another order of magnitude by
| running something like Gemma 4 on cloud hardware, or even
| more on local hardware.
|
| If this trend continues another 3 years, what costs 20k
| today might cost $100.
| omcnoe wrote:
| Difference is the scaffold isn't "loop over every file" -
| it's loop over every discovered vulnerable code snippet.
|
| If you isolate the codebase just the specific known
| vulnerable code up front it isn't surprising the
| vulnerabilities are easy to discover. Same is true for
| humans.
|
| Better models can also autonomously do the work of writing
| proof of concepts and testing, to autonomously reject false
| positives.
| slashdave wrote:
| Signal to noise
| letitgo12345 wrote:
| Can't you execute the bug to see if the vulnerability is real?
| So you have a perfect filter. Maybe Mythos decided w/o
| executing but we don't know that.
| cyanydeez wrote:
| so what you're saying is no one could ever write a loop like:
|
| for githubProject in githubProjects opencode command
| /findvulnerability end for
|
| Seems like a silly thing to try and back up.
| tredre3 wrote:
| What he's saying is that you should read the "Caveats and
| limitations" section of the article.
|
| Here's the first one:
|
| > Our tests gave models the vulnerable function directly,
| often with contextual hints (e.g., "consider wraparound
| behavior").
|
| Mythos did no such thing, it was cut lose and told to find
| vulnerabilities. If the intent was to prove that small models
| are just as good, they haven't demonstrated that at all. The
| end.
| WhyNotHugo wrote:
| OTOH, this article goes too far the opposite extreme:
|
| > We isolated the vulnerable svc_rpc_gss_validate function,
| provided architectural context (that it handles network-parsed
| RPC credentials, that oa_length comes from the packet), and
| asked eight models to assess it for security vulnerabilities.
|
| To follow your analogy, they pointed to the exact room where
| the gold was hidden, and their model found it. But finding the
| right room within the entire continent in honestly the hard
| part.
| mattmanser wrote:
| Or would it have any way if they hadn't pointed it at it? Who
| knows?
|
| Just like people paid by big tobacco found no link to cancer
| in cigarettes, researchers paid for by AI companies find
| amazing results for AI.
|
| Their job literally depends on them finding Mythos to be
| good, we can't trust a single word they say.
| hoppp wrote:
| They pay me 20k and give me time maybe I find it also.
| glerk wrote:
| I'm having trouble finding this info (I assume they won't
| publish it), but could the secret sauce be much larger and more
| readily accessible context window?
|
| OpenBSD's code is in the 10s of millions of lines. Being able
| to hold all of it in context would make bug finding much
| easier.
| johnfn wrote:
| You can look at some of the bugs, if you'd like. They are (at
| least the ones I looked at) fairly self-contained, scoped to
| a single function, a hundred lines or less. There's no need
| for a massive amount of context.
| lukev wrote:
| This is a really interesting point though -- it's really
| scaffold-dependent.
|
| Because for the same price, you could point the small model at
| each function, one by one, N times each, across N prompts
| instructing it to look for a specific class of issue.
|
| It's not that there's no difference between models, but it's
| hard to judge exactly how much difference there is when so much
| depends on the scaffold used. For a properly scientific test,
| you'd need to use exactly the same one.
|
| Which isn't possible when Anthropic won't release the model.
| lmeyerov wrote:
| Instead of scanning more code, afaict what you seem to want is
| instead, scan on the same small area, and compare on how many
| FPs are found there. A common measure here is what % of the
| reported issues got labeled as security issues and fixed. I
| don't see Mythos publishing on relative FP rate, so dunno how
| to compare those. Maybe something substantively changed?
|
| At the same time, I'm not sure that really changes anything
| because I don't see a reason to believe attacks are constrained
| by the quality of source code vulnerability finding tools, at
| least for the last 10-15 years after open source fuzzing tools
| got a lot better, popular, and industrialized.
|
| This might sound like a grumpy reply, but as someone on both
| sides here, it's easy to maintain two positions:
|
| 1. This stuff is great, and doing code reviews has been one of
| my favorite claude code use cases for a year now, including
| security review. It is both easier to use than traditional
| tools, and opens up higher-level analysis too.
|
| 2. Finding bugs in source code was sufficiently cheap already
| for attackers. They don't need the ease of use or high-level
| thing in practice, there's enough tooling out there that makes
| enough of these. Likewise, groups have already industrialized.
|
| There's an element of vuln-pocalypse that may be coming with
| the ease of use going further than already happening with
| existing out-of-the-box blackbox & source code scanning tools .
| That's not really what I worry about though.
|
| Scarier to me, instead, is what this does to today's reliance
| on human response. AI rapidly industrializes what how attackers
| escalate access and wedge in once they're in. Even without AI,
| that's been getting faster and more comprehensive, and with AI,
| the higher-level orchestration can get much more aggressive for
| much less capable people. So the steady stream of existing
| vulns & takeovers into much more industrialized escalations is
| what worries me more. As coordination keeps moving into machine
| speed, the current reliance on human response is becoming less
| and less of an option.
| rakel_rakel wrote:
| Spending $20000 (and whatever other resources this thing
| consumes) on a denial of service vulnerability in OpenBSD seems
| very off balance to me.
|
| Given the tone with which the project communicates discussing
| other operating systems approaches to security, I understand
| that it can be seen as some kind of trophy for Mythos. But
| really, searching the number of erratas on the releases page
| that include "could crash the kernel" makes me think that
| investing in the OpenBSD project by donating to the foundation
| would be better than using your closed source model for
| peacocking around people who might think it's harder than it is
| to find such a bug.
| paulddraper wrote:
| You don't see the value of vulnerabilities as on the order of
| 20k USD?
|
| When it's a security researcher, HN says that's a squalid
| amount. But when its a model, it's exorbitant.
| rakel_rakel wrote:
| If I understand you correctly, you're asking me if I would
| class this as a 20k USD (plus environmental and societal
| impact) bug? nope, I don't.
|
| I've not said anything else than that I think this specific
| bug isn't worth the attention it's getting, and that 20k
| USD would benefit the OpenBSD project (much) more through
| the foundation.
|
| > When it's a security researcher, HN says that's a squalid
| amount. But when its a model, it's exorbitant.
|
| Not sure why you're projecting this onto me, for the
| project in question $20k is _a_lot_. The target fundraising
| goal for 2025 was $400k, 5% of that goes a very long way
| (and yes, this includes OpenSSH).
| andy_ppp wrote:
| I wonder if you could just setup a small model and suggest a
| load of things and try every file and it might still end up
| being cheaper and just as good as Mythos at a specific task.
| Maybe this will be something that holds true for more things,
| formulating a small model to do specific things may well end up
| being as effective/efficient as a larger model looking at a
| huge solution space.
| antirez wrote:
| Congrats: completely broken methodology, with a big conflict of
| interest. Giving specific bug hints, with an isolated function
| that is suspected to have bugs, is not the same task, NOR
| (crucially) is a task you can decompose the bigger task into. It
| is basically impossible to segment code in pieces, provide pieces
| to smaller models, and expect them to find all the bugs GPT 5.4
| or other large models can find. Second: the smarter the model,
| and less the pipeline is important. In the latest couple of days
| I found tons if Redis bugs with a three prompts open-ended
| pipeline composed of a couple of shell scripts. Do you think I
| was not already tying with weaker models? I did, but it didn't
| work. Don't trust what you read, you have access to frontier
| models for 20$ a month. Download some C code, create a trivial
| pipeline that starts from a random file and looks for
| vulnerabilities, then another step that validates it under a
| _hard_ test, like ASAN crash, or ability to reach some secret,
| and so forth, and only then the problem can be reported. Test
| yourself what it is possible. Don 't let your fear make you
| blind. Also, there is a big problem that makes the blog post
| reasoning not just weak per se, but categorically weak: if small
| model X can find 80% of vulnerabilities, if there is a model Y
| that can find the other potential 20%, we need "Y": the
| maintainers should make sure they access to models that are at
| least as good as the black hats folks.
| nsbsbdjdididi wrote:
| Thanks Dario, very cool!
| Departed7405 wrote:
| Exactly, this is so flawed. Anthropic themselves said they only
| reported <1% of the vulnerabilities found, cause the rest is
| unpatched.
|
| Give open models an environment (prior to Feb 15- so no Mythos-
| discovered vulns are patche) of Linux and see how many
| vulnerabilities it can find. Then put it in a sandbox and see
| if it can escape and send you an e-mail.
| slopinthebag wrote:
| Idk, it seems reasonable to me
|
| > "Our tests gave models the vulnerable function directly,
| often with contextual hints. A real autonomous discovery
| pipeline starts from a full codebase with no hints. The models'
| performance here is an upper bound on what they'd achieve in a
| fully autonomous scan. That said, a well-designed scaffold
| naturally produces this kind of scoped context through its
| targeting and iterative prompting stages, which is exactly what
| both AISLE's and Anthropic's systems do."
|
| Also they included a test with a false positive, the small
| models got it right and Opus got it wrong. So this paper shows
| with the right approach and harness these smaller models can
| produce the same results. Thats awesome!
|
| So, if you're struggling to make these smaller models work it's
| almost certainly an issue of holding them wrong. They require a
| different approach/harness since they are less capable of
| working with a vague prompt and have a smaller context, but
| incredibly powerful when wielded by someone who knows how to
| use them. And since they are so fast and cheap, you can use
| them in ways that are not feasible with the larger, slower,
| more expensive models. But you have to know how to use them, it
| requires skill unlike just lazily prompting Claude Code,
| however the results can be far better. If you aren't
| integrating them in your workflow you're ngmi imo :) This will
| be the next big trend, especially as they continue to improve
| relative to SOTA which is running into compute limitations.
| woodruffw wrote:
| > Those models recovered much of the same analysis
|
| This is an essentially unquantifiable statement that makes the
| underlying claim harder to believe as an external party. What
| does "much" mean here? The end state of vulnerability
| exploitation is typically _eminently_ quantifiable (in the form
| of a functional PoC that demonstrates an exploited end state), so
| the strong version of the claims here would ideally be backed up
| by those kinds of PoCs.
|
| (Like other readers, I also find the trick of pre-feeding the
| smaller models the "relevant" code to be potentially
| disqualifying in a fair comparison. Discovering the relevant code
| is arguably one of the hardest parts of human VR.)
| Retr0id wrote:
| And what about the false-positive rate?
| dataflow wrote:
| Yeah, this is the critical question. If the model ends up
| flagging too much, that could end up being like a manual read
| of the code.
| tptacek wrote:
| If you cut out the vulnerable code from Heartbleed and just put
| it in front of a C programmer, they will immediately flag it.
| It's obvious. But it took Neel Mehta to discover it. What's
| difficult about finding vulnerabilities isn't properly
| identifying whether code is mishandling buffers or holding
| references after freeing something; it's spotting that in the
| context of a large, complex program, and working out how
| attacker-controlled data hits that code.
|
| It's weird that Aisle wrote this.
| ctoth wrote:
| > It's weird that Aisle wrote this.
|
| No, writing an advertisement is not weird. What's weird is that
| it's top of HN. Or really, no, this isn't weird either if you
| think about it -- people lookin for a gotcha "Oh see, that new
| model really isn't that good/it's surely hitting a wall/plateau
| any day now" upvoted it.
| goekjclo wrote:
| It's not weird. Top of HN is worthless as a barometer at this
| point, people downvote for calling out AI slop.
| sanex wrote:
| Nah, Saturday post. Less news less content.
| kennywinker wrote:
| If it's obvious when you look close, then automate looking
| close. Seems simple to write tools that spider thru a code
| base, finding logical groupings and feeding them into an LLM
| with prompts like "there is a vulnerability in this code, find
| it".
|
| The thesis is, the tooling is what matters - the tools (what
| they call the harness) can turn a dumb llm into a smart llm.
| roywiggins wrote:
| Right, but they didn't actually test that, did they?
| tptacek wrote:
| _Hold on, I misread your comment because I 'm knee-jerk about
| code scanners, which were the bane of my existence for a
| while. Reworking... and: done. The original comment was just
| the first graf without the LLM qualification. Sorry about
| that._
|
| The general approach without LLMs doesn't work. 50 companies
| have built products to do exactly what you propose here;
| they're called static application security testing (SAST)
| tools, or, colloquially, code scanners. In practice, getting
| every "suspicious" code pattern in a repository pointed out
| isn't highly valuable, because every codebase is awash in
| them, and few of them pan out as actual vulnerabilities
| (because attacker-controlled data never hits them, or because
| the missing security constraint is enforced somewhere else in
| the call chain).
|
| Could it work with LLMs? Maybe? But there's a big open
| question right now about whether hyperspecific prompts make
| agents more effective at finding vulnerabilities (by sparing
| context and priming with likely problems) or less effective
| (by introducing path dependent attractors and also
| eliminating the likelihood of spotting vulnerabilities not
| directly in the SAST pattern book).
| bluGill wrote:
| I have long said that static checkers get ten false
| positives. note that size of the code is not a
| consideration, it doesn't matter if it the four line 'hello
| world' or the 10 million line monster some of us work on,
| it is ten max false positive.
| SoftTalker wrote:
| It's also that humans are very bad at repetitive detailed
| tasks. Sitting down with a code base and looking at each
| function for integer overflow comparison bugs gets boring
| really fast. It's a rare person who can do that for as long as
| it takes to find a bug that they don't already have some clues
| about.
|
| It's the flaw in the "given enough eyeballs, all bugs are
| shallow" argument. Because eyeballs grow tired of looking at
| endless lines of code.
|
| Machines on the other hand are excellent at this. They don't
| get bored, they just keep doing what they are told to do with
| no drop-off in attention or focus.
| ____tom____ wrote:
| And there aren't enough security researchers in the world to
| review ALL the files from OpenBSD.
|
| And if there were, the cost would be more like $20M than 20K.
|
| Having all code reviewed for security, by some level of LLM,
| should be standard at this point.
| throwatdem12311 wrote:
| idk man, pay me enough money and I'll look at as much code as
| you want looking for integer overflows
|
| Would it be cheaper than Claude Mythos doing it? No idea.
| Maybe, maybe not.
|
| But it's weird how we're willing to throw away money to a
| megacorp to do it with "automation" for potentially just as
| much if not more as it would cost to just have big bounty
| program or hiring someone for nearly the same cost and doing
| it "normally".
|
| It would really have to be _substantially_ less cost for me
| to even consider doing it with a bot.
| tredre3 wrote:
| > idk man, pay me enough money and I'll look at as much
| code as you want looking for integer overflows
|
| So would I, but it doesn't negate that we, humans, are bad
| at this. We will get bored and our focus will begin to
| drift. We might not notice it, we might not want to admit
| it, but after a few continuous hours we will start missing
| things.
| drc500free wrote:
| It's like not differentiating between solving and verifying.
|
| "PKI is easy to break if someone gives us the prime factors to
| start with!"
| tombert wrote:
| It's weird, because when working on a big project, taking a
| break for a week or two, and returning to it, I will find a bug
| and will see hundreds of lines of code that are absolutely
| terrible, and I will tell myself "Tom you know better than to
| do this, this is a rookie mistake".
|
| I think people forget that it's hard to be clever and tidy 100%
| of the time. Big programs take a lot of discipline and an
| understanding of the context that can be really hard to
| maintain. This is one of several reasons that my second draft
| or third draft of code is almost always considerably better
| than the first draft.
| tucnak wrote:
| The point of contention is whether Mythos is the product of its
| intelligence or its harness; the results like this, and other
| similar testimonies, call into question too-dangerous-to-
| release marketing, and for good reason, too. Because it is
| powerful marketing. Aisle merely says the intelligence is there
| in the small models. I say, it's already clear that competent
| defenders could viably mimic, or perhaps even eclipse what
| Mythos does, by (a) making better harness, (b) simply spending
| more on batch jobs, bootstrapping, cache better, etc. You may
| not be doing this yourself, but your probably should.
| tptacek wrote:
| Aisle and Anthropic are literally talking about two different
| problem spaces.
| herf wrote:
| There are a lot of details in the original article, in most cases
| comparing with Opus, which required "human guidance" to exploit
| the FreeBSD vulnerability:
|
| https://red.anthropic.com/2026/mythos-preview/
|
| Also "isolating the relevant code" in the repro is not a detail -
| Mythos seems to find issues much more independently.
| robotswantdata wrote:
| They found a nail in a small bucket of sand, vs mythos with the
| entire beach reviewed.
| ctoth wrote:
| > They recovered much of the same analysis
|
| Really?
|
| > We isolated the vulnerable vc_rpc_gss_validate function,
| provided architectural context (that it handles network-parsed
| RPC credentials, that oa_length comes from the packet), and asked
| eight models to assess it for security vulnerabilities.
|
| No.
| lordofgibbons wrote:
| Without showing false-positive rates this analysis is useless.
|
| If your model says every line if your code has a bug, it will
| catch 100% of the bugs, but it's not useful at all. They tested
| false-positives with only a single bug...
|
| I'm not defending anthropic and openai either. Their numbers are
| garbage too since they don't produce false-positive rates either.
|
| Why is this "analysis" making the rounds?
| davebren wrote:
| It should at least get the same coverage anthropic got then, if
| not more.
| sfink wrote:
| Yes, and in this case they pointed at the function, so a 1-bit
| model ("yes") would be correct. But it's not that bad. First,
| they included a test with a false positive. The small models
| got it right, Opus got it wrong. Second, they asked for an
| analysis. Look for "Exploitation reasoning, single follow-up
| prompt:" in the post. It's hard to tell how good they were at a
| glance, though apparently the full logs are available so you
| could pull them up.
|
| Anyway, it seems like they erred in the up-front claim "small
| models found the vulnerability we pointed directly at!", but
| the findings are at least somewhat stronger if you read through
| the details.
|
| The small models didn't match Mythos at exploitation. They
| suggested plausible exploits, but didn't actually try them out
| so I can't tell if they would have worked. Deepseek R1's sounds
| pretty convincing to me, but I'm not a good judge. (I'm more in
| the space of accidentally writing vulnerabilities, not seeking
| them out or exploiting them. Well, ok, I have a static analysis
| that finds some, at least.)
| bhouston wrote:
| This is quite misleading.
|
| If you isolate the positive cases and then ask a tool to label
| them and it labels them all positive, doesn't prove anything.
| This is a one-sided test and it is really easy to write a tool
| that passes it -- just return always true!
|
| You need to test your tool on both positive and negative cases
| and check if it is accurate on both.
|
| If you don't, you could end up with hundreds or thousands of
| false positives when using this on real-world samples.
|
| The real test is to use it to find new real bugs in the midst of
| a large code base.
| rvnx wrote:
| Where are all the people here who claim that LLM are just useless
| stochastic parrots ? Did they lose internet ?
| SoftTalker wrote:
| The patterns of buggy code are well trained.
| eiens wrote:
| The bigger point of focus is that the enterprise value
| accrues to assets associated with software production.
|
| What happened to all that nonsense about LLM's solving
| physics, science etc? Lmao that certainly is not happening.
|
| The natural home of LLM's is in relation to software
| production.
|
| The question is can Anthropic and OAI survive? If OAI can't
| make their entry into the ad business work then they will
| fight over the same territory. Meaning both of their chances
| of survival drop as Google who is a monster in relation to
| software production will not only seek to kill them but buy
| their GPU's at a discounted price.
| operatingthetan wrote:
| My theory is that Mythos is basically just Opus with revised
| context window handling and more compute thrown at it. So while
| it will be a step forward, it is probably primarily hype.
| appcustodian2 wrote:
| N model is basically just N-1 model with revised context window
| handling and more compute thrown at it
| nickdothutton wrote:
| POC of GTFO should apply to AI models too, or the false positive
| rate will overwhelm.
| vmg12 wrote:
| The technique Anthropic uses was demonstrated by Nicholas Carlini
| in a talk he gave 2 weeks ago and it's very simple, when asking
| LLMs to review code, ask them to focus its review on one file in
| a single session. Here is the video with the timestamp (watch
| through to ~5:30, they show two different ways of prompting
| claude).
|
| https://youtu.be/1sd26pWhfmg?t=204
|
| https://youtu.be/1sd26pWhfmg?t=273
|
| IMO the big "innovation" being shown by Mythos is the
| effectiveness with prompting LLMs to look for security
| vulnerabilities by focusing on specific files one at a time and
| automating this prompting with a simple script.
|
| Prompting Mythos to focus on a single file per session is why I
| suspect it cost Anthropic $20k to find some of the bugs in these
| codebases. I know this same technique is effective with Opus 4.6
| and GPT 5.4 because I've been using it on my own code. If you
| just ask the agent to review your pr with a low effort prompt
| they are not exhaustive, they will not actually read each changed
| file and look at how it interacts with the system as a whole. If
| the entire session is to review the changes for a single file,
| the llm will do much more work reviewing it.
|
| Edit: I changed my phrasing, it's not about restricting its
| entire context to one file but focusing it on one file but still
| allowing it to look at how other files interact with it.
| mirsadm wrote:
| How is that going to find anything that interacts across files?
| vmg12 wrote:
| My phrasing wasn't clear but you aren't telling it to _only_
| look at one specific file but to focus its review on one
| file. Updated my original comment.
| appcustodian2 wrote:
| I would think that it is still capable of exploring the
| codebase and reading other related files like any other
| coding agent already does.
| nodja wrote:
| You misunderstood.
|
| Instead of asking the model: "Here's this codebase, report
| any vulnerability." you ask. "Here's this codebase, report
| any vulnerability in module\main.c".
|
| The model can still explore references and other files inside
| the codebase, but you start over a new context/session for
| each file in the codebase.
| TacticalCoder wrote:
| I don't dispute the fact that it's more than cool that we have a
| new tool to find security exploits (and do many other things)
| but... A big shoot-out to OpenBSD?
|
| We're literally talking about the biggest computers on the planet
| ever, trained with the biggest amount of data ever available to a
| system, with the biggest investment ever made by man or close to
| it and...
|
| The subtlest security bug it can find required: going 28 years in
| the past and find a...
|
| Denial-of-service?
|
| A freaking DoS? Not a remote root exploit. Not a local exploit.
|
| Just a DoS? And it had to go into 28 years old code to find that?
|
| So kudos, hats off, deep bow not to Mythos but to OpenBSD? Just a
| bit, no!?
| mrifaki wrote:
| finding vulns in a large codebase is a search problem with a huge
| negative space and what aisle measured is classification accuracy
| on ground-truth positives, those are different tasks so a model
| that correctly labels a pre-isolated vulnerable function tells me
| almost nothing about that model's ability to surface the same
| function out of a million lines of unrelated code under a
| realistic triage budget
|
| the experiment i'd want to see is running each of the small
| models as an unsupervised scanner across full freebsd then return
| the top-k suspicious functions per model and compute precision at
| recall levels that correspond to real analyst triage budgets, if
| mythos s findings show up in the small models top 100, i'd call
| that meaningful but if they only surface under 10k false
| positives then the cost advantage collapses because analyst
| triage time is more expensive than frontier model compute to
| begin with
|
| second thing i keep coming back to is the $20k mythos number is a
| search budget not a model cost, small models at one hundredth the
| per-token price don't give us one hundredth the total budget when
| the search process is the same shape, i still run thousands of
| iterations and the issue for autonomous vuln research is how fast
| the reward signal converges and the aisle post doesn't touch any
| of this
| cedws wrote:
| Didn't they also use Mythos to scan Linux many times over and it
| only found one DoS bug or something? I find it hard to believe
| there is only one security bug lurking.
| elzbardico wrote:
| I think that probably Mytho's mojo comes from a lot of post-
| training on this kind of task.
|
| I occasionally pick up contract work doing coding annotation to
| make some quick extra money, and a few months ago one of the
| projects was heavily focused on spotting common memory access
| bugs in C and C++.
| hedgehog wrote:
| It's strange to me they didn't reduce to PoC so the quantitative
| part is an apples-to-apples comparison. You don't need any fancy
| tooling, if you want to do this at home you can do something like
| below in whatever command line agent and model you like. A while
| back I did take one bug all the way through remediation just out
| of curiosity.
|
| """
|
| Your task is to study the following directive, research coding
| agent prompting, research the directive's domain best practices,
| and finally draft a prompt in markdown format to be run in a loop
| until the directive is complete.
|
| Concept: Iterative review -- study an issue, enumerate the
| findings, fix each of the findings, and then repeat, until review
| finds no issues.
|
| <directive>
|
| Your job is to run a security bug factory that produces
| remediation packages as described below. Design and apply a
| methodology based on best practices in exploit development, lean
| manufacturing, threat modeling, and the scientific method. Use
| checklists, templates, and your own scripts to improve token
| efficiency and speed. Use existing tools where possible. Use
| existing research and bug findings for the target and similar
| codebases to guide your search. Study the target's development
| process to understand what kind of harness and tools you need for
| this work, and what will work in this development environment. A
| complete remediation package includes a readme documenting the
| problem and recommendations, runnable PoC with any necessary data
| files, and proposed patch.
|
| Track your work in TODO.md (tasks identified as necessary) LOG.md
| (chronological list of tasks complete and lessons) and STATUS.md
| (concise summary of the current work being done). Never let these
| get more than a few minutes out of date. At each step ensure the
| repo file tree would make sense to the next engineer, and if not
| reorganize it. Apply iterative review before considering a task
| complete.
|
| Your task is to run until the first complete remediation package
| is ready for user review.
|
| Your target is <repo url>.
|
| The prompt will be run as follows, design accordingly. Once the
| process starts, it is imperative not to interrupt the user until
| completion or until further progress is not possible. Keep output
| at each step to a concise summary suitable for a chat message.
|
| ``` while output=$(claude -p "$(cat prompt.md)"); do echo
| "$output"; echo "$output" | grep -q "XDONEDONEX" && break; done
| ```
|
| </directive>
|
| Draft the prompt into prompt.md, and apply iterative review with
| additional research steps to ensure will execute the directive as
| faithfully as possible.
|
| """
| cmiles8 wrote:
| Mythos is clearly a nice improvement. It's also clear there's a
| lot of unfounded hype around it to keep the AI hype cycle going.
|
| Gating access is also a clever marketing move:
|
| Option A: Release it but run out of capacity, everyone is annoyed
| and moves on. Drives focus back to smaller models.
|
| Option B: A bunch of manufactured hype and putting up velvet
| ropes around it saying it's "too dangerous" to let near mortals
| touch it. Press buys it hook, like, and sinker, sidesteps the
| capacity issues and keeps the hype train going a bit longer.
|
| Seems quite clear we're seeing "Option B" play out here.
| throwaway13337 wrote:
| So there are two competing narratives:
|
| 1. Mythos uniquely is able to find vulnerabilities that other
| LLMs cannot practically.
|
| 2. All LLMs could already do this but no one tried the way
| anthropic did.
|
| The truth is one of these. And it comes down whether the
| comparison is apples to apples. Since we don't know the exact
| specifics of how either tests were performed, we lack a way of
| knowing absolutely.
|
| So I guess, like so many things today, we can to pick the truth
| we find most comfortable personally.
| goldenarm wrote:
| People have found 0days assisted by LLMs for a while, and none
| of them wrote hype pieces to find an excuse not to release
| their 10x bigger model in the middle of a GPU shortage.
|
| https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-...
| bryantwolf wrote:
| All of this discourse seems very bizarre.
|
| If smaller models can find these things, that doesn't mean mythos
| is worse than we thought. It means all models are more capable.
|
| Also if pointing models at files and giving them hints is all it
| takes to make them find all kinds of stuff, well, we can also
| spray and pray that pretty well with llms can't we.
|
| It just points to us finding a lot more stuff with only a little
| bit more sophistication.
|
| Hopefully the growing pains are short and defense wins
| davebren wrote:
| > If smaller models can find these things, that doesn't mean
| mythos is worse than we thought. It means all models are more
| capable.
|
| It means "it's so dangerous we can't release it" was a blatant
| lie since anthropic would have already known this.
| bryantwolf wrote:
| Sure, I think it's reasonable to tell Anthropic the barn door
| is already open.
|
| Though, like, I guess I expect that when this comes out, all
| the opus traffics will move over. It does appear to be much
| more capable, just jury is out about how much more capable
| abel_ wrote:
| This misses the broader ongoing trend. For a few million dollars,
| of course you can create a startup that builds tools it can use
| to more efficiently find code vulnerabilities. And of course you
| can do this with weaker models with scaffolds that incorporate
| lots of human understanding. The difference now is that you don't
| need an expensive team, nor a bunch of human heuristics, nor a
| million dollars. The requisite cost and skill are falling
| rapidly.
| yalogin wrote:
| Intuitively every existing model has already been trained on all
| code, all vulnerabilities reported, all security papers. So they
| all have the capability. Small models fall short because they may
| not be able to find a vulnerability that spans across a large
| function chain but for the most part they should suffice too.
|
| Of course I say this without any knowledge of what mythos is
| doing or how it's different. I am sure it's somehow different
| nomel wrote:
| Not intuitive at all. Not all models are equally capable, just
| because they had the same training data. The model architecture
| (as a whole) is very important. To reduce _capability_ , you
| can reduce layers, tool use, thinking, quantize it, etc. This
| is trivially proven by a cursory glance in the rough direction
| of any set of benchmarks (or actual use).
|
| Using small models as a classifier "there might be a
| vulnerability here" is probably reasonable, if you have a model
| capable of proving it. There are many companies attempting this
| without the verification step, resulting in AI vulnerability
| checker being banned left and right, from the nonsense noise.
| omcnoe wrote:
| The methodology here is completely wrong, outright dishonest.
|
| Finding a needle in a haystack is easy if someone hands you the
| small handful of hay containing the needle up front, and raises
| their eyebrows at you saying "there might be a needle in this
| clump of hay".
| chopete3 wrote:
| The impact of the Mythos announcement on the cybersecurity firms(
| like Crowdstrike,ZScalar etc) is big enough(10-15% drop in stock
| price) and this pushback is expected.
|
| Companies like Aisle.com (the blog) and other VAPT companies
| charge huge amounts to detect vulnerabilities.
|
| If Cloud Mythos become a simple github hook their value will get
| reduced.
|
| That is a disruption.
| zer00eyz wrote:
| Crowdstrike, no pe because it just had its first profitable
| quarter (38 million)
|
| ZScalar No PE
|
| Palo Alto Networks Inc (PANW) 86 PE
|
| Fortinet : (FTNT) 31.63 PE
|
| That last one, didn't get hit at all by the Mythos
| announcement, because at some level it has at least some
| grounding in fiscal reality.
| coppsilgold wrote:
| LLMs are wordsmith oracles. A lot of effort went into trying to
| coax interactive intelligence from them but the truth is that you
| could have probably always harnessed the base models directly to
| do very useful things. The instruct tuned models give your
| harness even more degrees of freedom.
|
| A while ago, the autoresearch[1] harness went viral, yet it's but
| a highly simplified version of AlphaEvolve[2][3][4].
|
| In the cybersecury context, you can envision a clever harness
| that probes every function in a codebase for vulnerabilities,
| then bubbles the candidates up to their callsites (and probes
| whether the vulnerability can be triggered from there) and then
| all the way to an interface (such as a syscall) where a potential
| exploit can be manifested. And those would be the low hanging
| fruit, other vulnerabilities may require the interplay of
| multiple functions. Or race conditions.
|
| [1] <https://github.com/karpathy/autoresearch>
|
| [2] <https://deepmind.google/blog/alphaevolve-a-gemini-powered-
| co...>
|
| [3] <https://arxiv.org/abs/2506.13131>
|
| [4] <https://github.com/algorithmicsuperintelligence/openevolve>
| AlexandrB wrote:
| The whole "this tool is too dangerous to be public" idea reeks of
| marketing. Just like all the "AI is an existential threat" talk a
| year ago. These companies are using ideas usually reserved for
| something like nuclear weapons to make their products look more
| impressive.
| npilk wrote:
| Wouldn't this mean we're even more cooked? I've seen this page
| cited a few times as evidence that Mythos is no big deal, but if
| true then the same big deal is already out there with other
| models today.
| davebren wrote:
| As cooked as we were pre-LLMs knowing that security exploits
| are relatively easy to learn about online and use, yet things
| keep chugging along.
| dominicq wrote:
| This would just speed up the discovery -> patch cycle, at
| least until such time that all the low hanging fruit
| (=represented in training data) is patched.
|
| Though another possibility would be that since LLMs generate
| so much code, the LLM vulnerability discovery would just keep
| chugging along and we'd simply settle for the same amount of
| potential vulns, same relative vulnerability-exploit-patch
| dynamics, though higher in absolute numbers.
| slibhb wrote:
| The best way to think of Anthropic's communication about Mythos
| is as advertisement. It's basically "our model is too smart to
| release" which suggests they're ahead of OpenAI (without proof)
| pardon_me wrote:
| The whole company is like that. If things were as amazing as
| advertised, they wouldn't even need to advertise. Or to release
| models to the public at all.
| boelboel wrote:
| Seen similar things with Openai and Palantir.
| slibhb wrote:
| Yes. OpenAI does the exact same thing.
| charcircuit wrote:
| The thesis that the system is more important than the model is
| not bitter lesson pilled. I would not bet on this in the long
| term. We will get to the point where you can just tell the model
| to go find and classify the severity of all security problems
| with a codebase.
| midnitewarrior wrote:
| At the center of every security situation is the question, "is
| the effort worth the reward?"
|
| We prepare security measures based on the perceived effort a bad
| actor would need to defeat that method, along with considering
| the harm of the measure being defeated. We don't build Fort Knox
| for candy bars, it was built for gold bars.
|
| These model advances change the equation. The effort and cost to
| defeat a measure goes down by an order of magnitude or more.
|
| Things nobody would have considered to reasonably attempt are
| becoming possible. However. We have 2000-2020s security measures
| in place that will not survive the AI models of 2026+. The
| investment to resecure things will be massive, and won't come
| soon enough.
| _pdp_ wrote:
| find ./ \( -name '*.c' -o -name '*.cpp' \) -exec agent.sh -p "can
| you spot any vulnerabilities in {}" \;
| abhinaystha wrote:
| Tech companies are just hyping their model to that the bubble
| wont burst so easily.
| nfcampos wrote:
| Anthropic marketing (and even supposedly technical write ups)
| _sadly_ has become more hyperbole and less substance over time
| imo. This technology is so impressive on its own, really feels
| like shootings themselves in the foot in the long run, but what
| do I know
|
| Case in point here where they conveniently fail to report the
| false positive rate, while also saying that if it wasn't for
| Address Sanitizer discarding all the false positives this system
| would have been next to useless
| decidu0us9034 wrote:
| Right now, we accept false positives as long as you can sort
| them out. I think it's pretty typical that >99% of fuzzer runs
| don't result in new coverage. Of course they're far from
| useless without feedback but it's better to have it if you can.
| I guess the question is does the llm approach have lower costs
| for validation and triaging vs just fuzzing alone, unclear to
| me. Anthropic would like people to believe automation is this
| scary new unknown
| palashdeb wrote:
| Been tracking this since the blog post, quick a big deal they are
| making it.
| thywis wrote:
| Sure, but it's more about whether the small model can find the
| vulnerability that bigger model can.
| mrinterweb wrote:
| I feel like there have been enough hyperbolic claims by
| Anthropic, that I'm starting to get some real Boy Who Cried Wolf
| energy. I'm starting to tune out, and assume it is a marketing
| ploy. Trust me, I'm an Antropic fan, and I pay my $200/month for
| max, but the claims are wearing thin.
| starboyy wrote:
| Tagline is very funny
| oliveiracwb wrote:
| I trust miracle models about as much as I trust my uncle's memes
| or three-day prosperity courses.
___________________________________________________________________
(page generated 2026-04-11 23:00 UTC)