In July 2026, an AI broke out of its sandbox and hacked a live production system on its own. 

During an internal OpenAI evaluation built to measure how far its models could push real exploitation, a pair of models, including GPT-5.6 Sol and an even more capable pre-release model, ran with their usual cyber safety refusals switched off. Fixated on solving the benchmark, one model went hunting for the answer key. It found and exploited a zero-day in a package registry cache proxy to escape its sandbox, escalated privileges and moved laterally until it reached the open internet, then chained stolen credentials and further zero-days into a remote code execution foothold on Hugging Face’s production infrastructure. 

No human directed those steps. The model reasoned its way to a novel attack path in a real-world system it had never seen the source code for, and Hugging Face’s own security team had to detect and contain it. OpenAI called it an unprecedented cyber incident, while Hugging Face’s CEO suspects it is the first of its kind. 

A year earlier, this was still a theory with a proof of concept. 

In May 2025, security researcher Sean Heelan published something that turned heads across the vulnerability research community: OpenAI’s o3 model had autonomously discovered a remotely exploitable zero-day in the Linux kernel.  

The bug, tracked as CVE-2025-37899, lives in ksmbd, the Linux in-kernel SMB server, and it surfaced from static analysis of roughly 12,000 lines of code with no fuzzer, no runtime instrumentation, and no human pointing the model at the vulnerable function. 

The same research effort produced a second result. A related use-after-free flaw, CVE-2025-37778, was found the old-fashioned way, through manual code review, then handed to o3 as a benchmark to see whether the model rediscovered it. It did, though inconsistently, and the hit rate exposed as much about the limits of AI code auditing as its promise. 

For SOC teams and vulnerability managers, the abstract conversation about AI in security is over. The same reasoning that helps a defender triage a CVE backlog is already helping attackers, and now autonomous systems, surface and exploit vulnerabilities at scale. 

In this month’s campaign, we’ll walk you through both ksmbd vulnerabilities, the discovery methods behind them, and what the shift means for red and blue teams. 

Understanding AI-assisted vulnerability discovery 

Large language models trained on vast corpora of source code and technical documentation are effective at static code review. They reason about control flow, object lifetimes, and concurrency across large files, and they flag subtle logic errors that traditional pattern-based scanners routinely miss. 

The ksmbd research demonstrates two distinct modes. In autonomous discovery, the model scans an unfamiliar codebase and surfaces candidate vulnerabilities with no prior knowledge of where a bug lives. In assistive analysis, the model validates a flaw a human already suspects, acting as a second set of eyes on a specific code path. Both modes compress the time and specialist expertise a bug hunt normally demands. 

What is ksmbd? 

ksmbd is a kernel-space implementation of the SMB3 protocol, introduced in Linux 5.15 in November 2021. It processes SMB requests directly in the kernel rather than in user space like Samba, which cuts context switches and boosts throughput for enterprise storage, NAS appliances, and modern Linux distributions. It also handles unauthenticated remote traffic in kernel space, which makes any memory-safety flaw inside it a high-value target. 

What is a use-after-free vulnerability? 

A use-after-free (UAF) occurs when code continues to reference a block of memory after that memory is freed. Once freed, the memory becomes available for reallocation, so a later dereference reads or writes data an attacker controls. In kernel space, where a corrupted object translates directly into memory corruption or privileged code execution, the consequences are severe. 

Both ksmbd bugs are use-after-free flaws on the same object: the session user structure. What differs is the trigger. One fires through a concurrency race with no authentication; the other fires through a reauthentication logic error that requires valid credentials. 

Anatomy of the ksmbd use-after-free flaws 

Both flaws corrupt the same session user object, but through different code paths. The first is an unauthenticated concurrency race; the second is an authenticated reauthentication error. 

CVE-2025-37899: How o3 autonomously discovered logoff 

The first flaw sits in the smb2_session_logoff() function in smb2pdu.c, and o3 found it by reasoning about multithreaded behavior across the codebase. 

1. Concurrent sessions 
   An attacker opens multiple concurrent SMB2/3 connections to a host running ksmbd, all sharing a single session structure. 

2. Logoff trigger  
   One connection issues a logoff command, which invokes smb2_session_logoff(). 

3. Incomplete idle check 
   Inside the handler, ksmbd_conn_wait_idle() checks only the current connection’s idle state. It ignores other connections still actively using the same session. 

4. Premature free 
   The function calls ksmbd_free_user(sess->user), freeing the session user object while sibling connections still hold references to it. 

5. The dangling access 
   Concurrently, another connection sends an SMB request such as a READ or WRITE that dereferences the now-freed user pointer. 

6. Corruption and execution 
   The result is a use-after-free. An attacker who grooms the freed memory achieves kernel memory corruption and, potentially, arbitrary code execution with kernel privileges. 

The critical property is that this path is network-accessible and requires no prior authentication.  

CVE-2025-37778: How the human-found, AI-validated Kerberos flaw works 

The second flaw lives in the session setup path, in smb2_sess_setup(), and it involves reauthentication rather than logoff. 

1. Authenticated setup request 
   An attacker with valid Kerberos credentials sends a crafted SMB2/3 session setup request over TCP port 445, reaching the Kerberos authentication logic. 

2. Premature free on a valid session 
   When the session state is already SMB2_SESSION_VALID, the handler frees the existing sess->user object with ksmbd_free_user() and sets the pointer to NULL. The underlying memory is already deallocated. 

3. Authentication without reinitialization 
   The function then calls ksmbd_krb5_authenticate(). The user object is never reinitialized, leaving the session in an invalid state. 

4. The dangling dereference 
   Any subsequent logic that dereferences sess->user after this point accesses freed memory, producing the use-after-free. 

5. Controlled corruption 
   By shaping the freed memory through crafted Kerberos authentication data, an attacker drives kernel memory corruption and potentially kernel-level code execution. 

Because exploitation requires valid credentials, the exposure is narrower than the logoff race. This CVE maps cleanly to MITRE ATT&CK T1068 (privilege escalation). 

What you’ll learn in this campaign 

Dive into the this Theory Module to explore how AI is reshaping the vulnerability lifecycle, from zero-day discovery through triage and detection. 

• Understand how large language models like o3 surface subtle memory-safety flaws that traditional static analysis tools miss. 

• Explore the anatomy of two ksmbd use-after-free vulnerabilities, CVE-2025-37899 and CVE-2025-37778, at the source-code level. 

• Investigate the difference between autonomous AI discovery and human-led analysis validated by AI. 

• Learn how the same AI capability serves both offensive research and defensive triage workflows. 

• Identify the defensive measures and detection strategies that reduce exposure to kernel-level SMB attacks.