Our research.
Rooted in Zurich, we advance novel vulnerability research with leading AI labs in San Francisco, hyperscalers and defense organizations. Our ambition is global: the best security, made easy for everyone.
We combine models because no single model finds everything, research which model works best for each task, and share reproducible research and open tools others can build on. The goal: software that secures itself.
Read the full manifesto- 30+
- merged 0-days in the Linux kernel
- 500+ CVEs
- confidential disclosure
- 30+
- software systems
Notes from the lab.
From a kernel finding to an upstream fix
Two accepted patches show different research paths: a missing lifetime reference in TIPC and an authorization check in VXLAN.
Read noteFinding the function wasn't enough
In a four-task binary-analysis experiment, the engine located suspicious code but produced no confirmed triggers. What that result says about discovery, and what it cannot tell us about recall.
Read noteA real bug. An incorrect claim of novelty.
A driver reproduced a known vulnerability, but our pipeline called it new. The mistake was treating an unfamiliar file hash as evidence of an unfamiliar bug.
Read noteTesting a Windows driver without its source
A stripped driver still exposes imports and dispatch structure. We used those signals to investigate known memory-access bugs, then checked the behavior under a kernel debugger.
Read noteFinding a bug in a stripped binary
A known color-profile bug exposed two problems in our analysis: function ranking and incomplete ground truth. Fixing them let the engine generate a differential reproducer.
Read noteWhat a clean sanitizer run doesn't prove
Two kernel race investigations showed why lifetime rules, test reachability, and exploitability need separate evidence. Silence from a sanitizer is only meaningful within what it can observe.
Read noteWhat maintainer review adds to AI research
The useful output of a kernel investigation is a clear report and a small, correct patch. Public review exposes the details an agent can overlook.
Read noteYour validator checked one value. Your app used another.
JavaScript properties can change between reads. Validation needs to account for the value the application actually uses, especially when inputs contain getters or proxies.
Read noteWhat counts as proof depends on the target
A protocol response, a sanitizer report, and a kernel crash answer different questions. The research record should make those differences visible.
Read noteA length field the NFC parser trusted
Linux's NFC service-discovery parser needed checks against the received packet and against each message type's minimum length. The defect illustrates why declared lengths are not buffer bounds.
Read noteWhen the test needs an authorization rule
A missing permission check may leave memory perfectly valid. Detecting it requires a test that knows which caller should be allowed to act.
Read noteCan a researcher find your security contact?
Our June survey found security.txt on about 1 in 10 sampled .ch domains. That measures a public contact file, not whether a company can receive reports.
Read noteWhat we lost when we filtered the findings
Our triage experiment reduced report volume, but some configurations also lost flags. Both sides of that tradeoff belong in the result.
Read noteBefore comparing scores, check what ran
Broken builds, retries, and an overly generous flag checker changed the meaning of our benchmark results. Here is how to keep those effects visible.
Read noteWhy we gave the agent a shell
An early web-testing experiment showed how tool interfaces can consume an investigation. A cookie jar made the problem concrete.
Read noteKeep the investigation outside the context window
Durable evidence, focused agent sessions, and explicit workflow stages make long research tasks easier to resume and verify.
Read noteReplacing a native SQLite dependency
A Node.js ABI mismatch led us to a WebAssembly SQLite build. The dependency became easier to install, but the adapter still needed careful testing.
Read noteIntroducing 0cloud
Managed security testing starts with a clear scope, a real target, and evidence an engineer can check.
Read noteTest what an AI application can actually do
AI security tests need to follow data access and tool permissions through the application, with a clear definition of success.
Read noteGive the verifier a fresh start
A separate verification pass can challenge a finding without inheriting its narrative. Its verdict still needs evidence.
Read noteWhat our npm audits taught us
Certificate validation, configuration parsing, and template loading exposed different trust-boundary mistakes. The useful part was turning each lead into a precise report.
Read noteSecurity review has to follow the change
AI-assisted development makes it easier to produce changes. Security testing still needs context, priorities, and a way to check its conclusions.
Read note
The public track record.
Every vulnerability we've disclosed. Each one links to its public record.
Securing the software behind the world’s leading technology companies.
CVE-2026-68124 · CNA 9.6 Critical
CVE-2026-77413 · GHSA-8gq3-vp5j-2grp
CVE-2026-63801
CVE-2026-72072
CVE-2026-68142 + CVE-2026-68432CVE-2026-68125CVE-2026-63831Queued upstreamCVE-2026-52746CVE-2026-63944CVE-2026-80803
Merged upstreamIn reviewIn reviewIn review
In reviewCVE-2026-80798CVE-2026-72091 + CVE-2026-72092
CVE-2026-89524CVE-2026-68197CVE-2026-74667CVE-2026-80800CVE-2026-80823
CVE-2026-89492
Merged upstreamIn reviewIn review
In review
In reviewIn reviewIn reviewIn reviewIn reviewQueued upstreamUpdated continuously. Embargoed findings appear once they're fixed.
Work with the lab.
You build critical software, or you break it for a living. Talk to us.