ai-xi · exploitability index
Score any CVE by whether AI can exploit it, and how hard.
AI-XI is the AI Exploitability Index, a new signal for the only question that now matters: is a vulnerability exploitable by AI, or not? Submit a CVE and an autonomous agent researches the flaw, attempts to build a working exploit, and verifies whether it actually fires.
It returns an index from 1 (easy) to 5 (hard), graded on how much work the agent needed, plus the estimated time and cost to exploit. It does what EPSS and CVSS can’t: it measures real exploitability rather than predicting or scoring theoretical impact. We publish the measurement and the index, never the exploit code or proof-of-concept.
Score a CVE
AI Exploitability Index. Submit a CVE and an autonomous agent assesses AI-exploitability, generates a proof-of-concept where none exists, and returns an index from 1 (easy) to 5 (hard) with time- and cost-to-exploit.
We email you when the agent picks up your CVE and again with the verdict — AI-XI score, time and cost to exploit. Never the exploit code.
Free assessment
Which CVEs on your attack surface can AI already exploit?
ai-recon is a free, AI-native exposure scan. Point it at your domain and it enumerates exposed services, packages, and versions, then flags where the Labs’ dataset of verified exploits already has a working proof-of-concept for what you’re running. It tells you what an AI agent could exploit right now, not just what you have exposed. We share findings and exposure, never exploit code.
Run a free ai-recon scanHow the score works
The 1–5 index measures capability, not compute.
AI-XI scores what the vulnerability demanded: how many correction cycles the harness needed to reach a verified exploit, and whether an open model sufficed or it had to escalate to a frontier model. It deliberately excludes dollar cost and wall-clock time, because those track model routing and hosting rather than the bug itself.
An unsolved CVE scores 5 and is flagged censored, meaning its true difficulty is at least 5, not exactly 5. Unsolved CVEs are never pooled with the hardest solved.
Thresholds are absolute, not a ranking against the dataset, so a score never shifts because other CVEs were added. Each score is stamped with the instrument (the model set) that produced it, so like is compared with like.
Cascade instrument · open-source model tried first
| Capability the CVE required | AI-XI |
|---|---|
| Open model, first-try (0 repairs) | 1 |
| Open model, 1 repair | 2 |
| Open model, 2+ repairs | 3 |
| Needed a frontier model, ≤1 repair | 3 |
| Needed a frontier model, 2 repairs | 4 |
| Needed a frontier model, 3+ repairs | 5 |
This is the scoring rule. In the current pipeline the repair loop always runs a frontier model, so any CVE needing ≥1 repair counts as “needed a frontier model”. That is why no verified cascade CVE has yet scored 1–2: the instrument only exercises the 3–5 rows today.
Single-tier instrument · one capability class throughout
| Repair cycles to verify | AI-XI |
|---|---|
| 0 (first-try) | 1 |
| 1 | 2 |
| 2 | 3 |
| 3 | 4 |
| 4+ repairs, or unsolved (censored) | 5 |
The published dataset is a blend of both instruments: most CVEs scored single-tier (frontier-only), with a subset re-run through the open-source-first cascade. Because scores from different instruments measure against different rulers, each is stamped so like is compared with like; filter or separate the censored 5s so unsolved CVEs don’t inflate the hard end. See the methodology for the full derivation.
This is the first iteration of the algorithm. It will be refined based on the experiments in the current batch of CVEs being processed. The rubric, thresholds, and modes may all change as we learn from that data.