The Usual Suspects

"The greatest trick the devil ever pulled was convincing the world he didn't exist." Public vulnerability databases are wrong at scale. In April 2026, a machine can verify it.

Two publications released two weeks apart in March and April 2026. No apparent connection between them. Read together, they describe the end of an equilibrium that held for twenty years.

The first, on March 27, comes from six researchers at Zhejiang University. They took 259 known Java exploits, ran them unmodified across 28,150 versions of 128 libraries, and compared the results with what the major vulnerability databases report. An unmodified exploit correctly identifies 83% of vulnerable versions with 99.3% precision. Better than NVD, better than GitHub Advisory, better than GitLab and Veracode. Only Snyk does slightly better in volume, at the cost of nine percentage points in precision¹.

The second, on April 13, comes from the UK's AI Security Institute. It is the cyber evaluation of Claude Mythos Preview, whose implications for AI-generated code, defensive frameworks and the CRA are documented in earlier articles in this series. The figure that matters here: 73% success rate on expert-level Capture the Flag challenges, and first model to fully complete a 32-step attack chain against a simulated enterprise network².

In plain terms

The first paper says that the official databases on which the entire defense of the software supply chain rests are wrong at scale. They miss entire branches, report the wrong library, ignore versions that hundreds of projects use in production. A blindly executed exploit finds the truth better than they do.

The second paper says that a machine can now, without human supervision, run those exploits at scale, adapt them when they fail, and discover new vulnerabilities on top of that.

These two facts share one consequence. For twenty years, the security of software dependencies has rested on a tolerable fiction: public databases were imperfect, but empirical verification was too expensive for everyone, defenders and attackers alike. The fiction held because no one could afford verification at scale. The machines that the AI Security Institute evaluated in April 2026 can.

Registry versus reality

When a developer wants to know whether a library they use is vulnerable, they check a public database. NVD is the US federal database hosted by NIST, the global reference registry. GitHub Advisory, GitLab Advisory, Snyk and Veracode are the four other major sources. Every commercial supply chain security tool, and especially the SCA scanners running in CI/CD pipelines, reads these databases and reasons on their statements.

The Chen et al. study measures what these five databases claim and compares their claims against a manually established ground truth. For each vulnerability, the researchers traced the commit that introduced it, verified the source code of each released version, and determined whether the flaw was present. Two experienced annotators, inter-rater agreement of 0.911 on the Cohen scale, a standard method in software engineering. The result is a ground truth against which the others can be tested¹.

The gaps are significant. Across the 259 vulnerabilities studied, a raw exploit identifies 796 vulnerable versions missing from NVD. The researchers reported them to the CPE team that maintains NVD, which confirmed it had made the corrections while noting a significant backlog on other pending reports¹.

Five types of omissions keep appearing. Misidentified libraries, with Snyk pointing to the parent module instead of the vulnerable one. Entire branches ignored, such as versions 2.10 and 2.11 of jackson-databind for CVE-2020-24616, left out. Truncated introduction ranges, with some CVEs going back much further than declared. Incorrect fix ranges, with versions later than the official patch still vulnerable. Unstable versions (RC, beta, alpha) systematically excluded even though Maven Central serves them to hundreds of projects¹.

The conclusion is direct. The informational layer on which all Java vulnerability management rests is incomplete and wrong at scale. Nobody had empirically verified it before this study. On April 15, 2026, NIST formalized what the data has been showing for months: universal CVE enrichment is abandoned, roughly 80% of submissions will be classified "Not Scheduled" for lack of capacity⁵.

Ten strategies, now automatable

In 17% of cases, the raw exploit fails due to differences between versions: a method name that changed, an argument type that evolved, an object chain that was reorganized. This detail changes everything when read in light of the AISI evaluation. The researchers manually migrated these exploits to the target versions and recovered 77% of the failures. Final recall rises to 96.1%¹.

They document ten migration strategies. These are precise operations. Trace renamings in source code diffs. Adapt argument types. Rebuild alternative gadget chains. Adjust verification assertions. This work takes 15 to 55 minutes per case for a senior software security engineer¹. For a human, it remains slow and expensive.

A model that completes a 32-step attack chain end to end can perform these operations. The ten strategies documented by Chen describe exactly the kind of transformation that this class of agent handles well: diff reading, API adaptation, targeted rewriting. What the Chen paper treats as a costly human limit collapses, now, into marginal machine cost.

The same shift holds outside closed models. The team that won DARPA's cyber challenge in 2025 measured, on Java, the two stages of a discovery: locating the flaw, then building the payload that triggers and proves it. With a frontier model, their system exploits 41 vulnerabilities out of 54; with GLM-5, an open-weight model under an MIT license that anyone can self-host, 35, for $392 in total against $2,400 to $3,100 for frontier models⁷. A model you download and run locally cannot be switched off from outside.

Verification switches sides

The defender relies on statements. When their scanner tells them a version is clean, they trust the registry. That registry is wrong in measurable proportions. The problem extends beyond versions. A University of Tennessee study published in April 2026 measures the reliability of another defensive signal: commit signing on GitHub⁶. The apparent signing rate is 89%. Remove the automatic signature that GitHub applies via its web interface, and the real rate falls to 5.94%. Of the 94% of "apparent signers," none had ever signed outside the browser. The "Verified" badge that developers and provenance frameworks (SLSA, in-toto) treat as a cryptographic identity attestation is, in the vast majority of cases, an attestation that the platform signed on behalf of the developer. An attacker who compromises a GitHub account inherits the green badge at no additional cost.

The attacker works by execution. They take a public exploit, they run it. If it works, the version is vulnerable. If it doesn't, they adapt.

This empirical verification by the attacker cost expert human time until now. An opportunistic attacker did not do this work. A targeted attacker did it on a specific target, never at the scale of an entire repository. This cost, and nothing else, kept the defender/attacker balance in place for twenty years. The quality of the databases and the cleverness of scanners had nothing to do with it. What mattered was the human cost of empirical verification.

An autonomous agent at Mythos level removes that cost. It can take every available public exploit, apply it to every version of a library, migrate the failing cases through the documented strategies, and produce an actual map of exploitable versions, without human supervision, at the scale of an entire repository, for the price of compute.

Nothing is moving on the defensive side. Databases remain incomplete. Scanners keep reading the same metadata. The joint Cloud Security Alliance / SANS / OWASP report released on April 12, coordinated by Gadi Evron, Robert T. Lee and Rich Mogull with contributions from Jen Easterly, Chris Inglis, Rob Joyce and Bruce Schneier, sums it up in one sentence: the cost of exploitation is collapsing, the window between disclosure and weaponization is compressing toward zero, and capabilities once requiring nation-state resources are becoming broadly accessible³.

Shipping code in 2026

A developer publishing a Java service today runs an SCA scanner on their CI pipeline. The scanner queries a public database, compares the versions of their dependencies against the declared affected versions, and returns a verdict. If the verdict says "no known vulnerability," the developer ships. The entire process rests on an implicit assumption: the public database knows which versions are affected.

The data destroys that assumption. The verdict "no known vulnerability" actually means "none of the public databases I consulted list this version as affected." Those two statements no longer mean the same thing. Between them lie the 796 versions missing from NVD, the ignored branches of jackson-databind, the RC versions Snyk excludes by policy while Maven Central distributes them.

Actual exploitability also depends on the runtime context. JDK version, operating system, transitive dependencies loaded in memory. Of the 2,447 documented exploit failures, 544 stem from a JDK incompatibility between the reference environment and the target environment¹. A fix deployed on JDK 11 says nothing about exploitability on JDK 17. No SCA scanner integrates this context today.

The Cyber Resilience Act enters full application on December 11, 2027⁴. It requires software vendors to track known vulnerabilities across the entire lifespan of the product. The obligation implicitly rests on the reliability of public databases. No article in the regulation addresses the case where these databases are wrong by construction. A vendor will be able to be fully CRA compliant and ship exploitable products to their customers without knowing it.

What I don't know

Java and Maven only. The transferability of the findings to npm, PyPI, Go or to C/C++ binaries is not demonstrated. I suspect the gap would be wider in dynamically typed environments and more variable in native compilations, but that suspicion remains to be validated.

The 96.1% post-migration rate describes laboratory conditions: senior experts, unlimited time, full access to source code, room for error. Neither the paper nor the AISI evaluations measure the actual yield of an autonomous agent applying these strategies blind to an unknown library base. I hypothesize that a Mythos Preview-level agent reaches a substantial yield, not the maximum human yield.

The AISI evaluations make clear that their test environments include no active defenders, no EDR, no real-time monitoring. The demonstrated capability applies to weakly defended systems. Extrapolating to hardened environments would be premature.

On open-weight models, what has been measured is the discovery of a vulnerability and the construction of the exploit that triggers it⁷. Migrating an exploit from one version to another, the precise operation described above, I have not seen quantified anywhere on these models. Autonomous exploitation of a full chain remains, as far as I know, above what they reach today, and I do not know how far these laboratory results transfer to real targets.

Conclusion

April 2026 brings together two facts that had nothing to do with each other. An empirical study measures that public vulnerability databases are wrong at scale. An official evaluation shows that an autonomous agent can now execute, adapt and chain exploits at the scale of an entire repository. Both phenomena describe the same reality viewed from two sides. The defender consults registries. The attacker runs tests. What kept this difference in balance for twenty years was the human cost of empirical verification. That cost has just fallen.

Vulnerability management based on trust in public registries is no longer defensible. Vendors who seriously want to know which versions of their dependencies are exploitable will have to verify empirically, on their own fleet, with their own tools. This requires compute, expertise, and an interpretation capability that does not exist in any commercial offering today. Building it will take years. The window for doing so is now measured in months.

Nineteenth article in a series on the structural flaws of Western cybersecurity (articles 1-5 in French):

• Article 1 : La vulnérabilité de la gestion des vulnérabilités
• Article 2 : La dépendance européenne aux standards américains
• Article 3 : Les États, architectes cachés du marché noir des vulnérabilités
• Article 4 : L'IA ou l'effondrement du modèle défensif occidental
• Article 5 : Desert Power — survivre sans l'Empire
• Article 6: I Am Altering the Deal
• Article 7: The Last Channel
• Article 8: Lord of Cyber War
• Article 9: The digital hawks
• Article 10: They Live... we sleep
• Article 11: Soylent Green
• Article 12: Ghost in the Binary
• Article 13: Now You See Me
• Article 14: The Prestige
• Article 15: Pitch Black
• Article 16: The Thing That Should Not Be
• Article 17: Status: clean
• Article 18: The Leopard

Sources

¹ Chen Z., Zhan Q., Zhou J., Hu X., Xia X., Yang X. "A Large-scale Empirical Study on the Generalizability of Disclosed Java Library Vulnerability Exploits." arXiv:2603.25997v1 [cs.SE], March 27, 2026. https://arxiv.org/abs/2603.25997

² AI Security Institute (UK). "Our evaluation of Claude Mythos Preview's cyber capabilities." AISI Blog, April 13, 2026. https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos-previews-cyber-capabilities

³ Evron G., Lee R.T., Mogull R. (et al.) "The 'AI Vulnerability Storm': Building a 'Mythos-ready' Security Program. Expedited Strategy Briefing." Cloud Security Alliance / SANS Institute / [un]prompted / OWASP Gen AI Security Project, April 12, 2026. Contributing authors: Jen Easterly (CEO RSAC, former CISA), Bruce Schneier (Inrupt, Harvard Kennedy School), Chris Inglis (former National Cyber Director, The White House), Phil Venables (Ballistic Ventures, former CISO Google Cloud), Heather Adkins (CISO Google), Rob Joyce (former Cybersecurity Director, NSA), Sounil Yu (CTO Knostic), Jim Reavis (CEO CSA), Katie Moussouris (CEO Luta Security), James Lyne (SANS), Dave Lewis (CISO 1Password), Joshua Saxe (Security Superintelligence Labs), Ramy Houssaini (CCSO Cloudflare), and others. https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/04/mythosready-20260413.pdf

Related journalism: Brumfield C. "Anthropic's Mythos signals a structural cybersecurity shift." CSO Online, April 13, 2026. https://www.csoonline.com/article/4158117/anthropics-mythos-signals-a-structural-cybersecurity-shift.html

⁴ Regulation (EU) 2024/2847 of the European Parliament and of the Council of October 23, 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Published in OJ L of November 20, 2024, entered into force on December 10, 2024, applicable from December 11, 2027. Manufacturer reporting obligations applicable from September 11, 2026. https://eur-lex.europa.eu/eli/reg/2024/2847/oj

⁵ NIST. "NIST Updates NVD Operations to Address Record CVE Growth." April 15, 2026. Only three categories of CVEs will be prioritized for enrichment: CISA KEV, federal government software, critical software (EO 14028). All others classified "Lowest Priority, not scheduled for immediate enrichment." Pre-March 2026 backlog moved to "Not Scheduled." See "Pitch Black" in this series for the full analysis of eight NIST degradation vectors. https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth

⁶ Shittu A., Herbold S., Morrison P. "Analysis of Commit Signing on GitHub." University of Tennessee, April 2026. 71,694 users, 874,198 repositories, 16 million commits. Apparent signing rate 89%, actual local signing rate 5.94%. 94.29% of apparent signers never signed outside the GitHub web UI. https://arxiv.org/abs/2604.14014

⁷ Fleischer F., Zhang C., Jang J., Cho J., Xu M., Kim T. "Contextualizing Sink Knowledge for Java Vulnerability Discovery." IEEE Symposium on Security and Privacy 2026 (to appear). Benchmark of 54 Java vulnerabilities across 22 open-source projects. With a frontier model, the GONDAR system exploits 41 of 54 vulnerabilities (sanitizer-verified proofs); with GLM-5 (open-weight, MIT license), 35, for $392 in total against $2,400 to $3,100 for frontier configurations. System built by Team Atlanta, winner of the DARPA AI Cyber Challenge 2025 (Georgia Tech, Samsung Research, KAIST, POSTECH). https://arxiv.org/abs/2604.01645