alt Hacker NewsAISLE’s autonomous analyzer found all CVEs in the January OpenSSL release
Comments
This really is quite scary.
I suspect this year we are going to see a _lot_ more of this.
While it's good these bugs are being found and closed, the problem is two fold
1) It takes time to get the patches through distribution 2) the vast majority of projects are not well equipped to handle complex security bugs in a "reasonable" time frame.
2 is a killer. There's so much abandonware out there, either as full apps/servers or libraries. These can't ever really be patched. Previously these weren't really worth spending effort on - might have a few thousand targets of questionable value.
Now you can spin up potentially thousands of exploits against thousands of long tail services. In aggregate this is millions of targets.
And even if this case didn't exist it's going to be difficult to patch systems quickly enough. Imagine an adversary that can drip feed zero days against targets.
Not really sure how this can be solved. I guess you'd hope that the good guys can do some sort of mega patch against software quicker than bad actors.
But really as the npm debacle showed the industry is not in a good place when it comes to timely secure software delivery even without millions of potential new zero days flying around.
Unfortunately you have to "request a demo" while supplying a company name and getting past a Cloudflare CAPTCHA.
So again this is not reproducible and everything is hidden behind an SaaS platform. That is apparently the future people want.
> Finding a genuine security flaw in OpenSSL is extraordinarily difficult.
history suggests otherwise
> The fact that 12 previously unknown vulnerabilities could still be found there, including issues dating back to 1998, suggests that manual review faces significant limits, even in mature, heavily audited codebases.
no, the code is simply beyond horrible to read, not to mention diabolically bad
if you've never tried it, have a go, but bring plenty of eyebleach
"We submitted detailed technical reports through their coordinated security reporting process, including complete reproduction steps, root cause analysis, and concrete patch proposals. In each case, our proposed fixes either informed or were directly adopted by the OpenSSL team."
This sounds like a great approach. Kudos!
So here we have OpenSSL, coded by humans, universally adopted by the Internet, universally deemed to be terrible code.
More evidence that "coding elegance" is irrelevant to a product's success, which bodes well for AI generated code.
OpenSSL is a very odd codebase, it's grown by accretion, under many stewards, with several flavours of coding belief, over time from SSLEAY which Eric Young coded over 2 decades ago. It had chip-specific speedups from the days of the Intel 486.
I was part of a body which funded work to include some stuff in the code, and the way you take something like X509 and incorperate a new ASN.1 structure inside the code, to be validated against conformance requirements (so not just signing blindly over the bitstream, but understanding the ASN.1 and validating it has certain properties about what it says, like not overlapping assertions of numeric ranges encoded in it) is to invoke callouts from deep down, to perform tasks and then return state. You basically seem to have to do about a 5 layer deep callout and return. It's a massive wedding cake of dependency on itself, it personifies the xkcd diagram of "...depends on <small thing>" risks.
I'm not surprised people continue to find flaws. I would like to understand if this approach also found flaws in e.g. libsodium or other more modern crytography, or in the OpenBSD maintained libreSSL code (or whatever it is) or Peter Gutmann's code.
OpenSSL is a large target.
I'm bearish on AI creating working software but bullish on AI doing this kind of thing
I don’t want to discredit the authors but just want to offer couple of hypothetical points in these paranoid times.
From a marketing angle, for a startup whose product is an AI security tool, buying zero-days from black market and claiming the AI tool found them might be good ROI. After all this is making waves.
Or, could it be possible the training set contains zero-day vulnerabilities known to three-letter agencies and other threat actors but not to public?
These two are not mutually exclusive either. You could buy exploits and put them in the training set.
I would not be surprised if it is legit though.
"Humans + AI" ...
Without Humans, AI does nothing. Currently, at least.
This sounds amazing but not too much info on how it worked
Does anyone have any recommendations on best practice security methods? As others have said, it sounds like there may be an order of magnitude more vulnerabilities found / exploited, and I'm wondering if security such as 2FA and Password Managers will be enough? Should people be getting on board with other protections such as security keys?
What's the kind of prompt / flow to get Claude to work on those security tasks?
Like any powerful tool, used responsibly in the right hands it could lead to great good; in the wrong hands or used irresponsibly, it could be extremely dangerous.
What kind of AI does this use?
I don't know why you're still using OpenSSL but if you're able to switch I note that BoringSSL was not affected by any of the January 2026 OpenSSL advisories, and was also not affected by any of the advisories from 2025, and was affected by only one of the 2024 advisories. I also note that I don't see any hasty commit activity to s2n-tls that looks like a response to these advisories.
Better software is out there.
Pretty impressive. Whether you think AI is a bubble or not, we all benefit from these findings.
As for all the slop the Curl team has been putting up with, I suppose a fool with a tool is still a fool.
Related:
AI discovers 12 of 12 OpenSSL zero-days (while curl cancelled its bug bounty)
https://www.lesswrong.com/posts/7aJwgbMEiKq5egQbd/ai-found-1...
The fun thing to me here is that a ton of really creative thinkers are going to have access to tools (LLM agents) that allow them to test their thinking quickly. I dearly hope that this leads to a prolonged phase of pain and loss.
We made good choices when we decided the information on the internet should be delivered by simple, open protocols.
We made bad choices when we decided that the information on the internet didn't need to be verified, or verifiable.
Then we slipped on our good choices, because our bad choices let robber barons claim the verified or verifiable case.
And then we were left an explosive entropy shit-pile.
But now the new tools the new overlords are paying us to use will help us break free from their shackles, bwahahahahahahahahahahahah!!!!
ok, so the USP for this analyzer is: 'He hackers, if you look for zero-days we've got the tool for you!'
The title change from "AISLE" to "AI" is misleading. As the article states,
> This doesn't mean that AI can replace human expertise. The OpenSSL maintainers' deep knowledge of the codebase was essential for validating findings and developing robust fixes. But it does change the SLA of security. When autonomous discovery is paired with responsible disclosure, it collapses the time-to-remediation for the entire ecosystem.
Only 12?
Related:
OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
[dead]
Link seems to be down... But also, considering curl recently shut down its bug bounty program due to AI spam, this doesn't really inspire much confidence.
Impressive.
I checked the stack overflow that was marked High, and Fil-C prevents that one.
One of the out-of-bounds writes is also definitely prevented.
It's not clear if Fil-C protects you against all of the others (Fil-C won't prevent denial of service, and that's what some of these are; Fil-C also won't help you if you accidentally didn't encrypt something, which is what another one of these bugs is about).
The one about forgetting to encrypt some bytes is marked Low Severity because it's an API that they say you're unlikely to use. Seems kinda believable but also ....... terrifying? What if someone is calling the AESNI codepath directly for reasons?
Here's the data about that one:
"Issue summary: When using the low-level OCB API directly with AES-NI or other hardware-accelerated code paths, inputs whose length is not a multiple of 16 bytes can leave the final partial block unencrypted and unauthenticated.
Impact summary: The trailing 1-15 bytes of a message may be exposed in cleartext on encryption and are not covered by the authentication tag, allowing an attacker to read or tamper with those bytes without detection."