FreeBSD CVE-2026-4747: RPCSEC_GSS stack overflow gives remote kernel code execution on NFS servers, found and exploited by Claude
A stack overflow in FreeBSD’s kgssapi lets a remote client run code in the kernel of an NFS server. Update to 15.0-p5, 14.4-p1, 14.3-p10 or 13.5-p11 and reboot.
- Published
- Updated
- Ecosystem
- Open source
- Fixed in
- FreeBSD 15.0-RELEASE-p5, 14.4-RELEASE-p1, 14.3-RELEASE-p10, 13.5-RELEASE-p11; stable/15, stable/14 and stable/13 after 26 March 2026
- Exploitation
- No in-the-wild exploitation reported; not in CISA KEV as of 30 October 2026; public root exploit published 31 March 2026
Live scores
CVE-2026-4747- EPSS
- 0.034
some chance of attack soon - VEDAS
- 0.519
some exploit evidence - On CISA KEV
- Not listed
- Detection rule
- None yet
What happened
On 26 March 2026, FreeBSD published advisory FreeBSD-SA-26:08. RPCSEC_GSS adds Kerberos authentication and encryption to Sun RPC services, including the NFS server. In the kernel it lives in the kgssapi.ko module. Each RPCSEC_GSS data packet is checked by a routine that copies part of the packet into a stack buffer without making sure the buffer is big enough. A malicious client can overflow it, and “this does not require the client to authenticate itself first” (FreeBSD).
The impact is code execution in the kernel of an NFS server that has kgssapi.ko loaded. Userspace RPC servers linked against the RPCSEC_GSS library are also vulnerable, though FreeBSD knows of none in the base system. All supported versions were affected (FreeBSD).
The advisory credits “Nicholas Carlini using Claude, Anthropic” (FreeBSD). On 7 April, Anthropic said its Claude Mythos Preview model found the bug and wrote a working exploit with no human involved after the initial request. The exploit split a ROP chain across six RPC requests and appended an attacker’s key to /root/.ssh/authorized_keys. If the server also runs NFSv4, an unauthenticated call leaks values the exploit needs; without NFSv4, Anthropic says an attacker could in principle brute-force them (Anthropic).
Separately, Calif published an exploit on 31 March that Claude wrote after the advisory was out. It gives a root reverse shell against an NFS server using Kerberos on port 2049, and the code is on GitHub (Calif).
No in-the-wild exploitation has been reported in the sources checked, and the CVE is not in CISA’s KEV catalog as of 30 October 2026 (CISA KEV).
Am I affected?
Your host is exposed if it runs an affected FreeBSD release and the kernel has RPCSEC_GSS loaded and untrusted hosts can send it NFS traffic.
# Running kernel and userland patch level
freebsd-version -kru
# Is RPCSEC_GSS in the kernel? (loaded module or compiled in)
kldstat -v | grep -i kgssapi
# Is the Kerberos NFS daemon enabled, and is NFS serving?
sysrc -n gssd_enable nfs_server_enable
sockstat -4 -6 -l | grep ':2049'You are on a fixed build if freebsd-version -k shows at least 15.0-RELEASE-p5, 14.4-RELEASE-p1, 14.3-RELEASE-p10 or 13.5-RELEASE-p11, or a stable branch built after 26 March 2026 (CVE record). Remember that freebsd-update install only changes the running kernel after a reboot.
Also check appliances built on FreeBSD that offer NFS with Kerberos. Their vendors need to ship the fix.
What to do now
- Update and reboot. For binary installs:
freebsd-update fetch,freebsd-update install, then reboot. For 15.0 systems installed from base packages:pkg upgrade -r FreeBSD-base, then reboot. Source builds can apply the patch fromhttps://security.FreeBSD.org/patches/SA-26:08/rpcsec_gss.patchand rebuild the kernel (FreeBSD). - If you cannot reboot yet and do not use Kerberos NFS, stop
gssdand unloadkgssapi(kldunload kgssapi), and keep it from loading at boot. FreeBSD offers no other workaround; kernels without it are not vulnerable (FreeBSD). - Limit who can reach NFS. Allow TCP and UDP 2049 only from known clients in your firewall. The exploit needs to send packets to the NFS server.
- Check userspace RPC servers you added yourself. Any daemon linked with the RPCSEC_GSS library that serves RPC is also vulnerable until the system is updated (FreeBSD).
Why this matters
This is one of the clearest early cases of an AI model finding and exploiting a remote kernel bug on its own, and a second AI-written exploit was public five days after the advisory. Kerberos NFS servers are usually inside the network, which limits exposure. But the gap between advisory and public exploit was days, not months.