Two more FreeBSD security fixes out of Anthropic Claude

cracauer@

Developer
Two more FreeBSD security fixes out of Anthropic Claude.

The two kernel security patches released today (both privilege escalation) have been marked as
Credits: Nicholas Carlini using Claude, Anthropic

I am unsure whether that specifically means that their public Claude LLM was used or whether this came out of Mythos.
 
ok , I'm doing Buildworld now on stable/15

DONE

$ uname -a
FreeBSD 15.1-PRERELEASE stable/15-n283066-9331e62e8b80

nice to see we got to 15.1 PRERELEASE
 
The two kernel security patches released today (both privilege escalation) have been marked as
Credits: Nicholas Carlini using Claude, Anthropic

I am unsure whether that specifically means that their public Claude LLM was used or whether this came out of Mythos.
Carlini is, quite understandably, not in the habit of specifying in his report which model version was used.

For instance, here is the famous FreeBSD CVE-2026-4747 found using Mythos Preview, whose credit line was simply "Nicholas Carlini using Claude, Anthropic" too: https://www.freebsd.org/security/advisories/FreeBSD-SA-26:08.rpcsec_gss.asc

We know it was found using Mythos Preview because of Carlini's 7 April writeup: https://red.anthropic.com/2026/mythos-preview/
Mythos Preview fully autonomously identified and then exploited a 17-year-old remote code execution vulnerability in FreeBSD that allows anyone to gain root on a machine running NFS. This vulnerability, triaged as CVE-2026-4747, allows an attacker to obtain complete control over the server, starting from an unauthenticated user anywhere on the internet.
I imagine there will be a lot more Mythos Preview findings to come. If you read that 7 April writeup, it mentions several more FreeBSD vulnerabilities and exploits still undergoing responsible disclosure. Details are not provided for obvious reasons but there are pre-commitment hashes to prove they were already known at time of writing.

Incidentally some interesting tweets (or whatever they're called today) from Colin Percival, FreeBSD Release Engineering Lead, on 17 April: https://nitter.net/cperciva/status/2044120206814171220#m
If you are reporting security issues to an open source project, PLEASE INDICATE WHETHER YOU USED AI TO FIND THEM.

I'm not saying this because teams want to be able to filter out "AI slop". I'm saying this because it's important for teams to be aware of the AI state of the art.

If you're worried about having reports ignored because you say you used AI, say "I have independently verified these, but used AI to find them". (Or even better "used <specific AI model> to find them".)
In reply to a question asking if he's serious:
We absolutely care. Both in terms of keeping track of what's going on in the world, and also in terms of "hey, we're getting lots of bugs which were found by foo, maybe we should be using it proactively".
The proactive use part is a glimpse into the future. Rather like fuzzing, LLMs are a tool both attackers and defenders can use.
 
If the submitter is a natural human and ...
  • using AI/LLM for finding bugs (including vulnerabilities)
  • not using AI/LLM for creating the fix itself, or if not, locally review the generated code not only "working" but also whether or not it's readable, maintainable and worth committing
  • make 100% sure that the LLM used doesn't trained using non-BSD-compatibully licensed codes (in case BSD OS'es) nor unpaid non-free materials (includes documents and so on) not to cause huge amount of penalty fees in the future
  • the natural human submitter confirms that there's no good-enough PRs yet on submitting,
it would be acceptable even if AI/LLM is used. Just my opinion.
 
[*]make 100% sure that the LLM used doesn't trained using non-BSD-compatibully licensed codes (in case BSD OS'es) nor unpaid non-free materials (includes documents and so on) not to cause huge amount of penalty fees in the future

I don't think that exists. Government have made pretty clear that anything goes as long as it makes the local AI industry more competitive, so all licensing went out the window before any of the current LLMs were trained.

I don't see a single LLM for coding that advertises itself as not having used GPLed input.
 
I don't think that exists. Government have made pretty clear that anything goes as long as it makes the local AI industry more competitive, so all licensing went out the window before any of the current LLMs were trained.

I don't see a single LLM for coding that advertises itself as not having used GPLed input.
For finding bugs only, it MAY be OK, but for generating codes, I cannot be 100% sure how courts judge such kind of violations in the future.
This is why I'm not even started evaluating AI myself. Because it CAN be too attractive to use it for code generations. I cannot take the risk.
 
For finding bugs only, it MAY be OK, but for generating codes, I cannot be 100% sure how courts judge such kind of violations in the future.
This is why I'm not even started evaluating AI myself. Because it CAN be too attractive to use it for code generations. I cannot take the risk.

You are not alone in this.
 
Why don't they find 10K problems and bugs in 1 week? That not being the case questions the additional value of AI at finding weaknesses in public software, as well as its overall capability since it apparently doesn't work without human process operation.
I think it's a p&r campaign and they reward their own people per exploitable problem. Ofcourse you can use it to find things fast in a fat LLM database but that's just software tech.
 
There were six new security advisories today. Of those, three CVEs were found by AISLE Research who are another group using AI to analyze code bases, detect and prioritise vulnerabilities, and propose fixes: https://aisle.com/about-us

Seems we'll be hearing plenty more about the role of AI in cybersecurity... here are AISLE's three.

FreeBSD-SA-26:16.libnv - Stack overflow via select() file descriptor set overflow (CVE-2026-39457)
FreeBSD-SA-26:15.dhclient - Remotely triggerable out-of-bounds heap write in dhclient (CVE-2026-42512)
FreeBSD-SA-26:12.dhclient - Remote code execution via malicious DHCP options (CVE-2026-42511)

There's also a bug found by Calif.io - given their previous form, that might well be an AI-assisted discovery too. See https://blog.calif.io/p/mad-bugs-claude-wrote-a-full-freebsd for the story that came out in March, though that one was only writing an exploit for a CVE already publicly announced (and which had been found, and it turns out already exploited, by Mythos Preview). They've been using AI to find vulnerabilities in a bunch of other projects too: https://blog.calif.io/archive?sort=new

FreeBSD-SA-26:13.exec - Local privilege escalation via execve() (CVE-2026-7270)
 
Back
Top