Here we explain the principle by which a model identifies a vulnerability, because it is useful for understanding current events. We provide no methods, no exploitable examples, and no tools. Understanding why a problem exists does not require knowing how to trigger it.
After an open model that reportedly found more than a thousand real flaws, the question deserves an explanation: how does a system that manipulates text manage to do that?
What a flaw really is
A vulnerability is almost never a spectacular error. It is a gap between intention and behaviour.
A programmer writes code with a normal use case in mind. They assume that incoming data will have a certain shape, that a user will follow a certain path, that a value will stay within a certain range. Most of the time, these assumptions hold.
A flaw appears when a situation does not respect these implicit assumptions, and the program then behaves in a way no one had anticipated. The code does exactly what is written; it is what is written that does not match what was intended.
Why a language model is well suited
Here is the counter-intuitive point. Finding a flaw is not primarily an exercise in computation; it is an exercise in reading.
You need to understand what the code claims to do, often from its function names, its comments, and its structure. Then look for the places where that intention and the execution diverge. This is a task of text interpretation, and it is precisely what these systems do best, as we explained in our article on LLMs.
Three capabilities combine. Pattern recognition: certain constructs resemble errors already seen thousands of times in the training corpus. Multi-step reasoning: following the path a piece of data takes through several functions, which reasoning models enable. And large-scale reading: scanning hundreds of thousands of lines without fatigue.
A human expert is better than a model at deep, creative analysis. But they get tired, they skip passages that seem mundane, and they cannot re-read an entire project every week. Most flaws are not subtle: they are in code no one has reviewed for years. What changes with these tools is not the finesse of the analysis, but the fact that everything gets read.
What these systems do poorly
Three real limitations, and they explain why humans remain essential in the chain.
False positives. A model readily flags suspicious constructs that are not exploitable in practice. Triaging takes time, and a tool that produces a thousand alerts, nine hundred of which are false, can cost more than it saves.
Lack of exploitation context. Knowing that a gap exists does not tell you whether it is reachable under real deployment conditions. That assessment requires understanding the environment, not just the code.
Poorly calibrated confidence. As we explained in our article on calibration, a model asserts with the same confidence whether it is right or wrong. In security, a false certainty wastes days.
Why this skill has become the topic
It is at the heart of almost everything we have covered this summer. It explains why a lab is slowing its own development citing cyber capabilities. Why test environments struggle to contain models, a system trained to find flaws having the skill to find those of its own cage. And why the debate over publishing weights is so tense.
What to remember
There is nothing magical about this capability. A model reads code attentively, without tiring, and spots gaps between what is written and what seemed intended. A good human auditor does the same thing, better and much more slowly.
What changes, therefore, is not the nature of the work, but its cost. A task that required weeks of expertise becomes accessible in hours. As often happens, the transformation does not come from a new capability but from a collapse in the price of an old one. And as often happens, it benefits first those with the fewest constraints.