The homepage says something about AI guided fuzzing based on libfuzzer or AFL. Looks like they have the LLMs identify a bunch of interesting functions to test, generate some test harnesses, and then sort through the fuzzer findings at a high level, which sounds like a pretty good idea.

Their system can run with various models, they go into more details in this article.

https://aisle.com/blog/system-over-model-zero-day-discovery-...

It wouldn’t surprise me if AISLE uses many different providers’ models, and what’s holding back OpenAI and Anthropic is only using first-party models. Just because OpenAI and Anthropic have arguably the strongest models overall doesn’t mean their models are the strongest at finding any given class of vulnerability or lead to follow.

> Wow, this announcement is good content marketing.

Why do you think companies hire PMMs?

>All six are rated Low severity

This says it all. Nothing important was missing. This is marketing hype.

> what models the use under the hood

Presumably their own, wouldn’t they?

It defaults to gpt5.4 nano

https://github.com/weareaisle/nano-analyzer/blob/main/scan.p...

Curl has a well earned reputation for high quality code. If you find something there it means you are good. There is a lot of software where finding a vulnerability mostly means you bothered to look and are not completely stupid. Nobody is going to be impressed if you find an issue with something that everybody already knows is poorly coded.

Thank goodness because curl is a load bearing structure to the backend of the internet.

Anyone care to guesstimate how much effort there would be in creating an actually-secure curl and openssl? Using something like Common Lisp or Lean, instead of C.

i don't think this is correct. if you look at this article by the curl founder daniel stenberg (https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-v...), he talks about how he previously ran Mythos on curl and that it found 5 issues: 1 turned out to be a low severity CVE, 3 were false positives, and 1 just a bug. So a) Mythos detects low severity CVEs too, and b) it is fairly noisy

As far as I understand it, the other efforts have not reported most of their findings to upstream developers, focusing on critical findings only.

This is understandable because upstream interactions at scale are difficult.

It's a very unfortunate ligature imho because there is no distinction between f and t. Looks funky

PS: the image in the background looks like a nod to David vs Goliath, love that detail

i think a key missing part is that an LLM on its own can't find vulnerabilities, so it's always an AI + harness. even mythos, when used for finding zero-days, is using an actually surprisingly heavy handed and expensive scaffold. they literally make it run in parallel on ±all files and ask "what's wrong with this?". here from the mythos technical blog post [1]:

> To increase efficiency, instead of processing literally every file for each software project that we evaluate, we first ask Claude to rank how likely each file in the project is to have interesting bugs on a scale of 1 to 5. A file ranked “1” has nothing at all that could contain a vulnerability (for instance, it might just define some constants). Conversely, a file ranked “5” might take raw data from the Internet and parse it, or it might handle user authentication. We start Claude on the files most likely to have bugs and go down the list in order of priority.

So they process it in parallel, but AI-rank them based on vuln-likelihood first = exhaustive search with a heuristic filtering first

[1] https://www.anthropic.com/research/mythos-preview

I think you might be misunderstanding this? This is, from my understanding, what went down:

1. curl was scanned by many different things, including AISLE, and many bugs were fixed <- all this was in the past 2. curl a week ago was scanned again my Mythos and Codex Security, and both of them said: 0 issues found 3. the same curl was scanned by AISLE a day later, resulting in ~29 reports (based on the blog post and mastodon posts from Daniel Stenberg) 4. of these 29, 6 cleared the bar and got CVEs in curl 5. these 6 CVEs were just announced as fixed in curl 8.22.0 today, together with 4 more CVEs that were detected by other people prior to point 2. of this list

so imho it was head-to-head, the very same codebase => it's a legit comparison

"How many total vulnerabilities can your tool alone identify?" and "How many unique vulnerabilities can your tool identify?" are both valid comparisons to make IMO.

I guess this would also require models trained on pre-2023 data - or not trained on later curl code, changelogs, blog posts discussing curl security fixes, etc.

What would the correct terminology actually be here I wonder?