What we have found and disclosed, how we work, and the questions we are chasing next.
When one code path checks something, we look for the equivalent path that does not. The bug is often in the copy nobody updated.
Which path forgot the check?When one code path checks something, we look for the equivalent path that does not. The bug is often in the copy nobody updated.
What changes between the check and the use?A value can be valid when it is checked and different when it is used. We look for state that another thread, process, or caller can change in between.
Where does untrusted input end up?We follow untrusted input through every parse, decode, and copy to the code that finally acts on it. Two parts can each handle it correctly and still disagree about what it means.
What exactly is missing?When the work stalls, we write down the one step that is missing and design a bounded experiment to test it. The result goes on record either way.
What did the run show, and what did it not?Hashes, a matched control, an independent repeat, and the cause joined to its effect in the same run. In our write-ups, each claim is labelled Executed, Observed, Repeated, Source-only, Not established, or Not demonstrated. We do not round up.
Places where the documentation promises isolation and the code does not enforce it. We look at hypervisors, sandboxes, and container runtimes.
We judge a memory bug by what it lets an attacker do, not by the crash it causes. For each bug class, which reads, writes, and control-flow changes can it give you, and which can it not?
Model-serving stacks and agent runtimes execute native code and reach real resources. We study the paths where inference meets the operating system, the filesystem, and the network.
Identity, delegation, and access control across services and tenants. These bugs survive every scanner, because the code is correct and does the wrong thing.
If you have found a vulnerability in software we research, or in Edictum or this site, write to the security contact.