Zafran and Athena: Turning the First Wave of AI-Discovered Vulnerabilities into Protection

On September 28, Chainguard began the first coordinated disclosure wave from Athena, the industry coalition built to defend open source software against vulnerabilities discovered by frontier AI models. Zafran joined Athena in July as a mitigation partner. Through the coalition we received this set of vulnerabilities before disclosure, and we used that time to build protections our customers can deploy today.

This first wave covers 14 "silent" vulnerabilities, all in Java libraries: 1 critical, 1 high, 8 medium, and 4 low. Each has a fix in a newer upstream release, usually introduced as a side effect of refactoring or cleanup. None of them ever received a CVE or a public advisory, so scanners had nothing to report and security teams had no reason to push an upgrade. Our data shows the result. Affected versions are still in production across our customer base, including commons-lang3 3.13.0, which runs in 41% of our customer environments, and jjwt 0.9.1, released in July 2018, which carries this batch's critical authentication bypass.
‍

Why silent vulnerabilities matter now

We have written before about what Mythos-class models change for defenders. Upstream commits are signals, and AI can turn a published fix into a working exploit in hours. A silent fix used to get by on obscurity, because finding the bug from a commit took real expertise and time. That protection is gone. The same models finding new zero-days can read old fix commits and work backward to every version that never got the patch. A missing CVE never meant a vulnerability wasn't there, and now it doesn't even slow attackers down.

The fix for most of these vulnerabilities is to upgrade, and Chainguard's advisories spell out exactly which version to upgrade to. Upgrading is rarely quick. It competes with feature work, and it moves through testing and change management before it reaches production. Without a security advisory to justify it, that work often never gets scheduled at all. Now that these advisories are public, the upgrades will start, and for some libraries they are large ones: teams on jjwt 0.9.1 need to reach 0.12.0, and teams on rest-assured 2.9.0 need 5.3.0, three major versions ahead. Compensating controls protect those systems while the upgrades work through the queue, using tools teams already own.

‍

What pre-disclosure access made possible

Early access to the vulnerabilities themselves is as important as access to the models that find them. It gives defenders a head start over attackers, with detections and mitigations ready before an issue goes public.

That is the role Zafran plays in Athena. Zafran turned Athena advisory data for these disclosed vulnerabilities into mitigations customers can deploy preemptively, in whatever controls and configuration they already have in place: a custom IDS or IPS signature, a WAF rule, a reverse proxy or API gateway, a firewall, an EDR policy, or a runtime setting. Each one enforces the check the vulnerable code gets wrong, one layer further out.

The Zafran platform supplies the other half of the picture. Our Exposure Graph maps each finding to the specific assets running the affected component. It shows which of those assets are reachable from the internet and which compensating controls already sit in front of them. When a new advisory lands, customers can see where they are exposed, where they are already protected, and where a mitigation needs to be deployed. Because we match advisories against SBOM inventory, an affected library shows up even when no scanner has reported a vulnerability on it, which is exactly the blind spot silent vulnerabilities live in.
‍

What we see across the Zafran customer base

We measured each of the 14 advisories against production environments.

• The two most severe findings both have mitigations available today. The critical jjwt authentication bypass (CGP-xpq5-jm7p-884r) affects 8.4% of our customers, and the high-severity rest-assured remote code execution (CGP-q285-qppx-f8fx) affects 2.8%.
• A small number of packages account for most of the exposure. commons-lang3 3.13.0 is the most prevalent, present in 41% of our customers. jakarta.validation-api 3.0.2 (two advisories) and commons-collections4 4.5.0 each appear in 20% of customers.
• Internet reachability is low but uneven. Among affected assets, commons-validator 1.2.0 has the highest internet-facing share at 6.3%, followed by jjwt 0.5.1 at 4.5%.
• Four of the 14 advisories do not appear in our customer base at all. Knowing which advisories are irrelevant to your environment lets teams spend their time on the ones that matter.
• 7 of the 14 advisories have an available mitigation. Some of the remaining flaws sit where no network or endpoint control can observe them. A weak random number generator, for example, produces tokens that look normal on the wire. For those, the upgrade or Chainguard's backported build is the fix, and exposure context tells you which assets to prioritize.
  ‍

How long these versions have been running

The release dates make the case on their own. commons-validator 1.2.0 shipped in December 2005, and a fixed version followed in December 2006. Nearly twenty years later, that 2005 release still runs in 6.5% of our customers, and 6.3% of the affected assets are reachable from the internet.

That example is extreme, but the pattern holds across the batch. Half of the advisories present in our customer base affect versions released in 2018 or earlier, and for seven of those ten, a fixed version has been available for more than two years. Without a security advisory to point to, these upgrades never had a reason to move up anyone's queue. Age does vary: fixes for commons-collections4 and cxf-rt-rs-security-oauth2-saml shipped only this summer.
‍

The first wave, by prevalence

Strict match against the version each advisory analyzed, across Zafran production customers.

How to read this table: 

"% of customers" is the share of Zafran production customers with at least one affected asset. 

"% of scanned assets" is measured against assets carrying SBOM inventory. 

Internet reachability is measured as a share of each advisory's own affected assets. 

"Version released" is the release date of the specific affected version shown.

"Fix released" is the date of the first upstream release containing the fix.

What to do now

1. Upgrade where you can. Chainguard's advisories include exact affected version ranges and the target version for each fix. The patches are published in Chainguard's public repository (https://github.com/chainguard-dev/athena). Chainguard Libraries customers can adopt a remediated build with a one-line lockfile change, swapping in Chainguard's version of the same artifact. Teams that want to ingest the advisories directly can use Chainguard's public VEX feed (https://libraries.cgr.dev/openvex/v1/all.json).
2. Mitigate where you can't upgrade yet. For the 7 advisories with an available mitigation, Zafran customers can deploy it through the controls they already have in place.
3. Use exposure context to set the order. Start with affected assets that are internet-facing or business critical since the upgrade is the only path for those.
   ‍

Looking ahead

This first wave is intentionally modest. Chainguard reports a backlog of more than 21,000 validated zero-days behind this batch, and the higher-impact findings are still to come (https://www.chainguard.dev/unchained/athenas-disclosures-begin). Five further findings are moving through the Linux Foundation's Akrites process with upstream maintainers, and we are preparing mitigations for them ahead of disclosure.

The volume of AI-discovered vulnerabilities will keep rising, and defenders will need the same capabilities they needed for this wave at much larger scale: early access to findings, a clear view of where they are exposed, and a fast path to protection through controls they already own.

We are proud to contribute to Athena, and we will keep building mitigations for each wave as it lands.