Skip to content
Edictum Labs, home
Research area

Vulnerability
research

Long investigations into how software breaks, from kernel memory handling to the boundaries that are supposed to keep workloads apart.

Propose a collaboration
Focus
Systems · Memory · Isolation · AI
Advisories
1
Location
Europe · Remote
The work

Understand a system well enough to find what nobody was looking for.

Scanners find what they already know to look for. Research finds the rest.

Most security tooling matches signatures and patterns, so it finds bugs someone has already described. The findings that matter most are the ones no catalogue lists: an object freed while something still points at it, an assumption that holds on every path but one, a boundary the documentation promises and the code never enforces.

That work takes time and patience. It is the main thing Edictum Labs does.

Domains

Where the implementation detail decides the outcome.

In these areas, whether a boundary holds comes down to how the code was written.
  • Operating-system and kernel security
  • Memory corruption and memory safety
  • Virtualization and isolation boundaries
  • AI inference systems and native execution
  • Security architecture and trust boundaries
  • Implementation-level defect analysis
Approach

How we do the research.

01

Find the guarded sibling

When one code path checks something, we look for the equivalent path that forgot to. The check that exists tells us what the missing one should have been.
02

Follow the input and the timing

We trace untrusted input through every transformation to the code that finally uses it. Along the way we look for state that can change between the check and the use.
03

Name the missing step

When the work stalls, we write down the one step that is missing and design a bounded experiment to test it. A stall becomes a question with a yes or no answer.
04

Keep receipts

Hashes, a matched control, an independent repeat, and the cause and effect in the same run. A claim is Executed only when we ran it. Otherwise it is Observed, Source-only, Not established, or Not demonstrated.
Disclosure

We publish after the vendor has fixed it.

We do not publish private or unpatched vulnerability details.

When research touches third-party software, we follow coordinated disclosure. The vendor gets time to fix the issue before anything is public. We publish an advisory only once the vendor's fix and advisory are out, and list it on the research page.

See the security page for how we report and handle vulnerabilities.

Collaboration

Chasing the same bug class?

If you are researching kernel memory handling, isolation, or the native code behind inference, we are open to joint research, coordinated disclosure, and shared tooling. Write to the person doing the work.

Open to
Joint research · Disclosure · Tooling
Reply
Direct, from the researcher
Location
Europe · Remote