I built a system for vulnerability research that centers around AI note taking at its core and it led to finding four CVEs in containerd:
- CDI annotation smuggling (CVE-2026-53492)
- Checkpoint image-config LABEL host RCE (CVE-2026-53488)
- Checkpoint import tag poisoning (CVE-2026-50195)
- Arbitrary host file read via symlink following (CVE-2026-53489)
Looking at the other names on the credit list you can begin to see a funnel filter with many duplicate reporters on the high, then top research teams on two of the critical vulnerabilities, and then my solo critical. The advisories read like a roster of the best resourced AI teams in the field with Anthropic Research with Claude, Google’s GKE Security Team with Gemini, Microsoft, Trail of Bits, a group from Zhejiang University that all landed on the same checkpoint bugs within the same time frame, but importantly missed one critical. The methodology behind my approach to vuln research in general allows me to explore code flow, architecture, and system design with agents at my disposal rather than hunting for security problems directly. As a result I found all the same vulns in the same time frame plus more while deeply understanding the codebase. This allowed me to follow up with the maintainers and work with them on triage and threat modeling.
Why LLM vuln research converges
Independent researchers using LLMs kept reporting the same containerd checkpoint bug and probably with different models and providers. Three of my four findings landed as duplicates or shared advisories and locally when rerunning my research system I would rediscover the same vulns over again across both codex and claude code.
Historically SAST tools and human pentesters performed research they used flow based taint analysis (ex: control/data/source-to-sink) , black box testing, and representing code in various formats like graphs or ASTs. LLMs rely on these priors that are baked into its latent space which unfortunately we still don’t understand. Hacking in my opinion is the art of understanding the logic behind developers (or AI now) translating tasks into code and then twisting that baseline behavior to elicit unintended consequences.
It’s not like researchers or AI invent vulns in code, a compiler doesn’t magically know how many vulns exist at build time. In many applications the number of control flows is finite but just too large to compute or to abstract to understand what is security critical. Though if user input is the starting node in our flow that means that the finite search space is vastly reduced. This can be further optimized since the final destination node can remain abstract but reduced with blacklists (i.e. allow all sinks but remove known false positives).
Since LLMs naturally scale out to read all code paths with search capabilities as filters, that means we all end up hunting in the same way. At its core when a model’s latent space is doing vuln research we can only look at patterns in the outputs and infer from what it misses as much as it what it found.
The non convergent method
Traditional approaches commonly ask the question of does an attacker controlled value reach a dangerous sink in various different ways. For a stateful daemon that misses the most interesting surface of two benign operations separated in time joined by shared state. A low trust writer deposits something into node global state and a higher trust root reader later consumes it and acts. Neither is a bug alone and conveniently an LLM overlooked this latent connection.
What it uniquely found
The win is the critical GHSA-33vj-92qq-66hc (CVE-2026-53492), which I break down in containerd CDI Annotation Smuggling where the CRI implementation improperly trusts Container Device Interface (CDI) annotations found within untrusted checkpoint image metadata during container restoration. The vuln was found via that time faceted approach where reading notes produced by agents allowed me to steer them towards this conclusion. At the end of the day a hack is a valid PoC not a finding from a scanner, AI, or human so an abstract definition allows a subset of abstract creative solutions that LLMs struggle with.
Two evidence discipline to deal with LLM false positives
Additionally within my methodology I produce a claim that isn’t valid until it has two independent pieces of evidence. First ideally is a source trace on a fresh clone when auditing open source code. This creates static proof of our theory which we can formulate via automated agents or from the symbiotic setup of notes, agents and human drivers. Second, a harness (in this case go code) that exercises our theory in practice. These final findings are then reviewed deeply by myself and various AI agents and tested in a live GKE cluster which dogfoods containerd. Hopefully this is akin to a water filtration system with various phased coarse and grain levels of filters.
What is the role of an LLM in vuln research
A human driver with an LLM is a powerful tool for finding divergent and novel vulnerabilities. As intelligence on frontier models develop, what becomes the unique edge is not the engine in the race car but how good the driver is. Within a short period of time we will see the gap widen on vulnerabilities found and exploited. However, this is an engineering problem that can be divided and conquered by LLMs.
Though within all the intelligence of an LLM, a neural net still lacks the ability to strike a lightning bolt between unique approaches that come as insights to humans. LLMs can autonomously break code, implying there is a race to win but hackers break anything and don’t look for medals or benchmarks to track.
When the debate between cybersecurity capabilities becomes a measuring contest between OpenAI, Anthropic, or the plethora of open source models we quickly begin to forget that a human with that same LLM would crush all the scores.