Anthropic made headlines claiming Claude Mythos achieved the “first remote kernel exploit discovered and exploited by an AI.” We went looking for how - and found a 20-year-old bug hiding in plain sight.

Let’s break down exactly what we think Mythos did, and what it means for cyber defense.

What did Claude Find?

In Anthropic’s initial Claude Mythos post, they discuss multiple different vulnerabilities that Mythos discovered and exploited. The one with the most detail (including a CVE and full technical writeup) is CVE-2026-4747 - a remote code execution capability in FreeBSD’s networked file system. These networked filesystems are used across thousands of on-prem network storage systems in enterprise and academic research centers.

While the exploit demonstrates an impressive engineering feat, anybody following AI shouldn’t be surprised by the ability of an agentic harness to write code - we were personally more curious as to how it recognized the vulnerability in the first place. The write-up of the vulnerability notes the “textbook” nature of the vulnerability - a classic stack overflow, made even easier by standard protections (KASLR/Stack Canaries) that are not compiled into FreeBSD:

In sys/rpc/rpcsec_gss/svc_rpcsec_gss.c, the function svc_rpc_gss_validate() reconstructs an RPC header into a 128-byte stack buffer (rpchdr[]) for GSS-API signature verification. It first writes 32 bytes of fixed RPC header fields, then copies the entire RPCSEC_GSS credential body (oa_length bytes) into the remaining space — without checking that oa_length fits.

static bool_t
svc_rpc_gss_validate(struct svc_rpc_gss_client *client,
                    struct rpc_msg *msg, gss_qop_t *qop, rpc_gss_proc_t gcproc)
{
   int32_t rpchdr[128 / sizeof(int32_t)];  // 128 bytes on stack
   int32_t *buf;

   memset(rpchdr, 0, sizeof(rpchdr));

   // Write 8 fixed-size RPC header fields (32 bytes total)
   buf = rpchdr;
   IXDR_PUT_LONG(buf, msg->rm_xid);
   IXDR_PUT_ENUM(buf, msg->rm_direction);
   IXDR_PUT_LONG(buf, msg->rm_call.cb_rpcvers);
   IXDR_PUT_LONG(buf, msg->rm_call.cb_prog);
   IXDR_PUT_LONG(buf, msg->rm_call.cb_vers);
   IXDR_PUT_LONG(buf, msg->rm_call.cb_proc);
   oa = &msg->rm_call.cb_cred;
   IXDR_PUT_ENUM(buf, oa->oa_flavor);
   IXDR_PUT_LONG(buf, oa->oa_length);

   if (oa->oa_length) {
       // BUG: No bounds check on oa_length!
       // After 32 bytes of header, only 96 bytes remain in rpchdr.
       // If oa_length > 96, this overflows past rpchdr into:
       //   local variables → saved callee-saved registers → return address
       memcpy((caddr_t)buf, oa->oa_base, oa->oa_length);
       buf += RNDUP(oa->oa_length) / sizeof(int32_t);
   }

   // gss_verify_mic() called after — but overflow already happened
}

The buffer has only 128 - 32 = 96 bytes of space for the credential body. Any credential larger than 96 bytes overflows the stack buffer.

The Fix (14.4-RELEASE-p1)

The patch adds a single bounds check before the copy:

oa = &msg->rm_call.cb_cred;
if (oa->oa_length > sizeof(rpchdr) - 8 * BYTES_PER_XDR_UNIT) {
   rpc_gss_log_debug("auth length %d exceeds maximum", oa->oa_length);
   client->cl_state = CLIENT_STALE;
   return (FALSE);
}


Wow. Scary find - how many more deep kernel bugs that no human has ever noticed are out there?

Well, it turns out, the “first kernel exploit discovered by AI” claim might be true - but is definitely not the whole story.

Some History - What is svc_rpc_gss_validate?

This vulnerable code has roots in Sun Microsystem’s Open Network Computing Remote Procedure Call (ONC RPC) and its Network File System (NFS) - developed initially in 1984 and released in 1985.

As networks expanded from smaller trusted environments to the huge systems in the 90’s, Sun’s NFS and RPC protocols became a de-facto standard. So, in April 1995, Sun handed control of ONC RPC to the IETF to be maintained as an open standard (RFC 1790).

The IETF established a working group to develop this standard, which published the RPCSEC_GSS protocol in 1997 (RFC 2203). Much of the open-source work to implement NFSv4, RPCSEC_GSS, and the necessary kernel-level components was funded and developed by the Center for Information Technology Integration (CITI) at the University of Michigan.

The Wolverines are still credited in the headers of MIT’s Kerberos implementation to this day (the kind of notice human devs are used to seeing but not noticing), as well as in the nearly identical files that were copied into FreeBSD’s implementation.

 Copyright (c) 2000 The Regents of the University of Michigan.
 All rights reserved.

 Copyright (c) 2000 Dug Song <dugsong@UMICH.EDU>.
 All rights reserved, all wrongs reversed.

 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions
 are met:

 1. Redistributions of source code must retain the above copyright
    notice, this list of conditions and the following disclaimer.
 2. Redistributions in binary form must reproduce the above copyright
    notice, this list of conditions and the following disclaimer in the
    documentation and/or other materials provided with the distribution.
 3. Neither the name of the University nor the names of its
    contributors may be used to endorse or promote products derived
    from this software without specific prior written permission.

Wait - Did you say “Copied”?

FreeBSD maintains its entire base operating system - the kernel, the drivers, and the essential system utilities - in one massive, unified repository. This includes the RPCSEC_GSS functionality, which is virtually identical to code in MIT’s Kerberos (including Dug Song’s reversing of all wrongs!) and used by almost every Linux distribution to implement secure NFS operations.

So, you would expect Mythos’ CVE to be for MIT’s implementation too? Is it possible we have a bigger problem on our hands?

Please welcome, an oldie-but-goodie, CVE-2007-3999! NIST’s NVD describes this vulnerability as a:

stack-based buffer overflow in the svcauth_gss_validate function in lib/rpc/svc_auth_gss.c in the RPCSEC_GSS RPC library (librpcsecgss) in MIT Kerberos 5 (krb5) 1.4 through 1.6.2, as used by the Kerberos administration daemon (kadmind) and some third-party applications that use krb5, allows remote attackers to cause a denial of service (daemon crash) and probably execute arbitrary code via a long string in an RPC message.

This CVE was patched in 2007. But something about that description seems awfully familiar…

CVE-2007-3999… You ARE the Father!!

The last vulnerable version of Kerberos was 1.16.2. The side-by-side of the vulnerable function from 2007 (likely in Claude’s training data) with Mythos’ discovery is extremely telling:

Vulnerable Kerberos - 2007

// src/lib/rpc/svc_auth_gss.c
// Added 2 newlines to align bodies

static bool_t
svcauth_gss_validate(struct svc_req *rqst, struct svc_rpc_gss_data *gd, struct rpc_msg *msg)
{
struct opaque_auth *oa;
gss_buffer_desc rpcbuf, checksum;
OM_uint32 maj_stat, min_stat, qop_state;
u_char rpchdr[128];
int32_t *buf;

log_debug("in svcauth_gss_validate()");

memset(rpchdr, 0, sizeof(rpchdr));

/* XXX - Reconstruct RPC header for signing (from xdr_callmsg). */
buf = (int32_t *)(void *)rpchdr;
IXDR_PUT_LONG(buf, msg->rm_xid);
IXDR_PUT_ENUM(buf, msg->rm_direction);
IXDR_PUT_LONG(buf, msg->rm_call.cb_rpcvers);
IXDR_PUT_LONG(buf, msg->rm_call.cb_prog);
IXDR_PUT_LONG(buf, msg->rm_call.cb_vers);
IXDR_PUT_LONG(buf, msg->rm_call.cb_proc);
oa = &msg->rm_call.cb_cred;
IXDR_PUT_ENUM(buf, oa->oa_flavor);
IXDR_PUT_LONG(buf, oa->oa_length);
if (oa->oa_length) {
memcpy((caddr_t)buf, oa->oa_base, oa->oa_length);
buf += RNDUP(oa->oa_length) / sizeof(int32_t);
}
// Continues...
}

Vulnerable FreeBSD - 2026

// sys/rpc/rpcsec_gss/svc_rpcsec_gss.c
static bool_t
svc_rpc_gss_validate(struct svc_rpc_gss_client *client, struct rpc_msg *msg,
   gss_qop_t *qop, rpc_gss_proc_t gcproc)
{
struct opaque_auth *oa;
gss_buffer_desc rpcbuf, checksum;
OM_uint32 maj_stat, min_stat;
gss_qop_t qop_state;
int32_t rpchdr[128 / sizeof(int32_t)];
int32_t *buf;

rpc_gss_log_debug("in svc_rpc_gss_validate()");

memset(rpchdr, 0, sizeof(rpchdr));

/* Reconstruct RPC header for signing (from xdr_callmsg). */
buf = rpchdr;
IXDR_PUT_LONG(buf, msg->rm_xid);
IXDR_PUT_ENUM(buf, msg->rm_direction);
IXDR_PUT_LONG(buf, msg->rm_call.cb_rpcvers);
IXDR_PUT_LONG(buf, msg->rm_call.cb_prog);
IXDR_PUT_LONG(buf, msg->rm_call.cb_vers);
IXDR_PUT_LONG(buf, msg->rm_call.cb_proc);
oa = &msg->rm_call.cb_cred;
IXDR_PUT_ENUM(buf, oa->oa_flavor);
IXDR_PUT_LONG(buf, oa->oa_length);
if (oa->oa_length) {
memcpy((caddr_t)buf, oa->oa_base, oa->oa_length);
buf += RNDUP(oa->oa_length) / sizeof(int32_t);
}
// Continues...
}

The George Bush-era patch to Kerberos is also nearly identical to what FreeBSD implemented last month in response to Mythos:

*** src/lib/rpc/svc_auth_gss.c (revision 20474)
--- src/lib/rpc/svc_auth_gss.c (local)
***************
*** 355,360 ****
--- 355,369 ----
  memset(rpchdr, 0, sizeof(rpchdr));

    /* XXX - Reconstruct RPC header for signing (from xdr_callmsg). */
+ oa = &msg->rm_call.cb_cred;
+ if (oa->oa_length > MAX_AUTH_BYTES)
+ return (FALSE);
+
+ /* 8 XDR units from the IXDR macro calls. */
+ if (sizeof(rpchdr) < (8 * BYTES_PER_XDR_UNIT +
+      RNDUP(oa->oa_length)))
+ return (FALSE);
+
  buf = (int32_t *)(void *)rpchdr;
  IXDR_PUT_LONG(buf, msg->rm_xid);
  IXDR_PUT_ENUM(buf, msg->rm_direction);
***************
*** 362,368 ****
  IXDR_PUT_LONG(buf, msg->rm_call.cb_prog);
  IXDR_PUT_LONG(buf, msg->rm_call.cb_vers);
  IXDR_PUT_LONG(buf, msg->rm_call.cb_proc);
- oa = &msg->rm_call.cb_cred;
  IXDR_PUT_ENUM(buf, oa->oa_flavor);
  IXDR_PUT_LONG(buf, oa->oa_length);
  if (oa->oa_length) {
--- 371,376 ----

So, can AI find brand-spanking new, highly creative vulnerabilities? Maybe. But, in the case of CVE-2026-4747, the finding of the vulnerability itself seems much more an instance of combinatorial creativity, with AI making a discovery already within its training data.

There is a growing discussion around similar “rediscoveries” that AI has made in mathematics and other sciences, and it is cybersecurity’s turn to have this discussion. What, if any, are the boundaries on AI making genuinely new discoveries? Is the difference even important?

Bottom Lines

Understanding the true risk of AI in cybersecurity means separating the sci-fi hype from the reality of how these models actually work.

The Real Threat: Recycled Code

FreeBSD’s CVE was caused by human negligence in the early 2000’s.

But, in 2026, decades-old flaws are being baked directly into our systems faster than ever. LLMs, as they configure our environments and write new code, regurgitate the same insecure patterns they were trained on.

AI Will Find and Exploit These Flaws

Advanced models don't need to be highly creative to shut down a company or a power grid. They just need to act as powerful pattern-matchers, spotting and exploiting the legacy bugs that weaker AI models carelessly copy-pasted into the environment.

Agentic Defense is a Necessary Advantage

At the end of the day, it doesn’t matter if an exploit is “unique” or actually memorized training data. What matters is the harm it can cause when exploited - and AI has made exploitation far cheaper than it used to be.

But patching can still be cheaper and faster than attacking. The organizations that will come out ahead are the ones that turn to agentic capabilities before the attackers do.