AI-Assisted Researcher Builds Zero-Day Root Exploit for Linux Kernel Race Condition
A STAR Labs intern used AI to discover CVE-2026-53264, a use-after-free race condition in Linux's network traffic-control subsystem, and developed a working root exploit that the vulnerability had survived undetected for two to three years.
Lee Jia Jie was five months into an internship at STAR Labs when he handed over something that should have been caught years ago: a working exploit for a use-after-free race condition in the Linux kernel’s network scheduler that grants root privileges to any local user with shell access. The vulnerability, now tracked as CVE-2026-53264, had been sitting in the net/sched traffic-control subsystem for an estimated two to three years before discovery — a long lifespan for a bug this exploitable in a codebase this heavily scrutinized.
The research process itself is what makes this case worth watching. Lee used AI tools to assist with vulnerability discovery, KASAN proof-of-concept creation, and race window optimization across multiple stages of the work. That is a different claim than the standard narrative of AI-generated exploits flooding the landscape. What the tools actually did here was compress the timeline of a fairly specialized manual process — finding a race window, stabilizing it, and turning a crash into a reliable escalation.
The practical impact shows in the numbers. The exploit’s runtime dropped from over 15 minutes to approximately five seconds once AI assistance was applied to optimizing the race window — not because the AI wrote the final payload, but because it accelerated the iterative process of hitting a timing-dependent bug reliably. Race conditions are notorious for this: the vulnerability is real and exploitable, but building a demonstration that works consistently enough for coordinated disclosure or further research can consume months of engineering. Compression of that timeline matters for defenders as much as attackers, since it determines whether a bug gets reported with a working proof-of-concept or whether it lingers in the gap between “theoretically exploitable” and “demonstrably so.”
The net/sched subsystem is a particularly interesting place for this to happen. Traffic control in Linux handles packet queuing, shaping, and scheduling — the infrastructure that decides which packets wait and which get dropped under load. It is not peripheral code; it is the path that every packet traverses. A use-after-free here means a packet processing context that has been freed can still be accessed by another path, and in this case, that access can be steered toward privilege escalation rather than a simple crash. The subsystem has been probed heavily in the past, which makes the two-to-three year survival of this bug worth noting. Either the specific pattern Lee found was genuinely unusual, or the coverage of net/sched’s race surfaces has gaps that systematic tooling — AI-assisted or otherwise — is now beginning to close.
There is a temptation to treat this as a story about AI replacing human expertise in vulnerability research, and that reading is not quite right. Lee’s internship suggests someone already embedded in the field, working within STAR Labs rather than operating from outside it. The AI assistance appears to have operated on tasks that a skilled researcher would eventually complete manually — finding the vulnerability pattern, generating the KASAN report, squeezing the race window — but faster. That distinction matters for how the security community should think about tool adoption. If AI were generating novel exploit primitives from scratch, the threat model shifts dramatically. If it is accelerating known-good research workflows by an order of magnitude, the shift is still significant but more bounded.
What comes next is the harder question. A reliable local root on CentOS Stream 9 is a serious vulnerability, and the disclosure timeline will determine how many systems patch before details become public. The broader significance, though, is methodological. If AI-assisted tooling can surface and weaponize multi-year-old kernel races this efficiently, the effective age of Linux kernel vulnerabilities — the gap between introduction and discovery — may be compressing. Code that has survived past audit cycles is no longer quite as safe as it once appeared. That is not a novel observation in security, but it is one that acquires new weight when the toolset for systematic re-examination scales beyond what manual review can match.