Methodology

1. Objective and scope

This study measures the impact of artificial intelligence on the exploitation of known software vulnerabilities: whether an autonomous system can reproduce a working, verified exploit for a published CVE, and at what cost, speed, and success rate.

It is not zero-day research. We do not discover novel vulnerabilities. Every vulnerability analyzed is a known, published CVE with an assigned identifier and public advisory; the object of study is the changing economics of exploiting what is already known.

The engine behind this research is the Quantro Exploit Harness, a ground-breaking, fully autonomous exploitation system. The vulnerability dataset, threat context, and enrichment data behind the Harness are supplied by Loginsoft’s vulnerability research and intelligence practice. Standing up an environment, writing an exploit, and proving it fires has historically taken days of specialized, manual effort per vulnerability. The Harness does it autonomously, and at scale. The unit of analysis is a single CVE: for each one, the Harness constructs a self-contained, reproducible lab and proves the exploit against a deterministic verifier. All results are a snapshot of the April–June 2026 study window. Because AI capability improves over time, the figures represent a floor for that period rather than a fixed constant.

2. The AI Exploitability Index (AI-XI)

The central outcome of this study is a single metric that turns a plain question into a number: how hard is it for AI to exploit a given vulnerability?

AI-XI scores every vulnerability from 1 to 5. A 1 means the Harness exploited it trivially; a 5 means it was the hardest to solve, or could not be solved at all. The score reflects how much work the Harness needed to reach a verified exploit, chiefly how many correction cycles it took before the exploit passed. It deliberately ignores dollar cost and wall-clock time, which are set by hardware and model choices rather than by the vulnerability itself.

Two rules keep it honest:

• Unsolved counts as a lower bound. A vulnerability the Harness never exploited scores 5 and is flagged censored, meaning its true difficulty is at least 5, not exactly 5. Most score-5 vulnerabilities are unsolved rather than “hardest solved,” so we always report the two separately.
• Stable and comparable. Scores use fixed thresholds rather than a ranking against the rest of the dataset, so a vulnerability’s score never shifts because other vulnerabilities were added. Each score is also stamped with the instrument that produced it, so like is compared with like.

3. Vulnerability selection

Selection was exhaustive within the stated criteria. Every CVE meeting a criterion in scope was included, rather than a random or convenience sample, and the criteria were chosen to build in comparison groups rather than a single undifferentiated pool.

Vulnerabilities were selected on four criteria:

1. Software type. Open-source software (OSS), plus commercial software where it could be reproduced in a lab without purchasing expensive licensed products.
2. Public-PoC availability, sampled deliberately on both sides: vulnerabilities with no public proof-of-concept, and vulnerabilities with a public PoC as a comparison baseline.
3. CISA KEV. Vulnerabilities in the CISA Known Exploited Vulnerabilities catalog.
4. Recency. Recent vulnerabilities from 2024, 2025, and 2026 with no public PoC available.

Candidates entered the dataset through four sourcing streams, each with its own selection rule: the Quantro Risk Database (the standing CVE dataset), Loginsoft LoVi threat intelligence, internet-exposure signal (Shodan), and the CISA KEV catalog.

The resulting dataset comprises 3,029 CVEs, distributed across the selection axes as follows:

The dataset is OSS-throughout, with every entry carrying package-ecosystem coordinates. Commercial coverage is limited to freely reproducible targets and treated as opportunistic rather than as a measured stratum. A CVE was excluded when it could not be honestly measured: insufficient version or fix data to pin the vulnerable build, no viable path to reproduce it in a container, a determination that the flaw was not reachable, commercial software requiring paid licenses, or the absence of any real generation run (such cases are left unscored, never scored as trivial).

4. Data sources and enrichment

For each CVE, the Harness begins by assembling a comprehensive profile from the Quantro Risk Database, a broad set of data points that establishes an accurate, complete understanding of the vulnerability before any exploitation is attempted. That profile is then evaluated against three independent, external risk signals, used both to inform the lab and as the baselines this report measures AI-exploitability against: CVSS severity, FIRST EPSS v4 exploitation probability, and CISA KEV known-exploited status (snapshot dated 30 June 2026). EPSS scores were taken within the study window.

5. The exploitation pipeline

The Quantro Exploit Harness takes each CVE from identifier to verified lab through five stages. This is the autonomous pipeline that makes exploitation measurable at scale. Every stage writes a folder that the next stage reads, so any stage can be re-run independently. Within the Harness, two kinds of actor perform the work: deterministic code (fixed logic, no synthesis) and an AI agent (open-ended synthesis or judgment).

Discovery → Enrichment → PoC → Lab → Verify + Repair → verified lab

• Discovery (deterministic). Assemble the CVE’s profile from the Quantro Risk Database (§4).
• Enrichment (deterministic). Attach CVSS, EPSS, and CISA-KEV signals.
• PoC (AI + deterministic). Classify the vulnerability, locate the exploitable code path, determine how to reach and fire it, pin the exact vulnerable version, assemble the detection contract that will prove exploitation, perform a reachability check, and write the exploit. Synthesis is done by the AI agent; version pinning, contract assembly, gating, and bookkeeping are deterministic.
• Lab (AI + deterministic). Select the build strategy and success marker, write the vulnerability-specific core that makes the lab actually fire the vulnerability, and render the full containerized lab from templates. Only the vulnerability-specific core is authored by the AI agent; the lab scaffolding is rendered deterministically.
• Verify + Repair (deterministic verifier + AI repair). The credibility core, described in §6.

6. Verification and controls

A vulnerability is called AI-exploitable only when the Harness’s deterministic verifier proves it, never on the AI’s own assertion. A result counts as verified when exploitation is confirmed from evidence in the run output: the Harness builds the vulnerable target, launches it, fires the exploit, and observes the pre-declared success marker.

Every verified result additionally clears two controls. The negative control requires that the patched build does not fire the marker, proving the signal is the vulnerability rather than an artifact of the harness. The sham control requires that a benign input does not fire the marker, proving the exploit is specific to the malicious trigger. Both controls run inside the verification step on every study-window run, so a verified result is never a bare model assertion.

When verification fails, an AI repair step edits the lab and PoC files and the deterministic verifier re-runs; the AI never declares its own success. The loop is capped at a fixed number of attempts, and a CVE not verified within the cap is recorded as unsolved (scored 5 and censored, per §2).

Beyond the Harness’s automated verification, outputs were independently human-verified along a chain: an automated judge model and the Quantro research team reviewed exploitation outputs, and each was then manually verified for accuracy by Loginsoft. 998 CVEs carry this independent human verification, and of those 234 required a human to correct the AI-generated exploit before it would verify. The remaining 764 verified as generated. The standing goal is to human-verify the entire dataset; the 998 are the subset completed within the study window, selected operationally as labs became available and prioritized to batch-verify later exploits. It is therefore a convenience subset rather than a randomized sample, and per-subset rates should not be extrapolated to the full dataset as though randomly drawn.

7. Measured outcomes

For every CVE the pipeline records a verdict (verified, not exploitable, or unsolved), cost, wall-clock time, compute (tokens), the AI Exploitability Index (§2), and the enrichment baselines (CVSS, EPSS, KEV, public-PoC availability, in-the-wild status). Producing the full dataset took billions of tokens of inference end to end.

Cost is the total inference cost of a run at prevailing market rates for a combination of models; the specific model routing and configuration are held private. Because cost and wall-clock time depend on that routing and on hosting, they are reported as operational metrics and are deliberately excluded from the AI Exploitability Index.

8. Independence, release, and ethics

Vulnerability Research Labs (VRL) is a research unit of Quantro Security, in partnership with Loginsoft. Quantro built the exploitation pipeline and exploit harness and funded the compute. Loginsoft supplied the vulnerability dataset, threat context, and enrichment data, and independently verified outputs for accuracy. The methodological integrity is deliberate: deterministic verification, mandatory negative and sham controls on every result, independent third-party output verification, and a public, auditable dataset with the data to substantiate every claim. It is vendor-originated research, stated plainly as such.

The report and an accompanying dataset are released TLP:CLEAR. The dataset is a public repository of per-CVE attributes: CVE identifier, exploitability index, cost, tokens, and the enrichment baselines (CVSS, EPSS, KEV, public-PoC availability, in-the-wild status). It exists so that the report’s comparisons can be independently reproduced. Working exploit code and runnable labs are withheld; the study publishes its measurements, not its weapons. Only already-public CVEs are analyzed, no new vulnerabilities are disclosed, and all labs are contained.

9. Limitations

• Scope. Known, published CVEs only. This is not zero-day discovery, and the findings speak to the re-exploitation of the known rather than to novel vulnerability finding.
• Capability snapshot. Results are an April–June 2026 snapshot of a specific instrument. Capability improves between versions; these figures are a floor for that window.
• Survivorship and reproducibility bias. The dataset is limited to CVEs reproducible in a container. Vulnerabilities requiring hardware, licensed commercial software, or elaborate environments are under-represented, so the population skews toward what can be reproduced.
• What “verified” proves. A verified result demonstrates the pre-declared success marker, which is evidence of exploitation in the output. It does not demonstrate every possible downstream impact of the flaw.
• Enrichment coverage. Public-PoC and in-the-wild status are undetermined for roughly a quarter of the dataset; EPSS, CVSS, and KEV are point-in-time. Comparisons that depend on these signals use the enriched subset.
• Single-run measurement. The AI Exploitability Index is a pure function of one canonical run, and repair counts carry some variance. Scores are read with their instrument stamp.
• Operational metrics. Cost and time reflect this pipeline’s economics, not a universal price of exploitation, and vary with model routing and hosting.
• Independence. This is vendor-originated research with independent third-party output verification by Loginsoft. It is not fully third-party research.