- View all articles
Jackie Porter
Senior Director, Product Management
Chainguard
- View all articles
Cecelia Sanborn
Manager, Product Operations and Data
Chainguard
Jackie Porter Senior Director, Product Management + 1 other
Earlier this month, Dan wrote that the flood is coming and the pipes were already full: frontier models are finding vulnerabilities faster than the industry's disclosure and patching processes were ever built to absorb. Pouring findings faster into a system that's already backed up doesn't help anyone. You need a process that can take the volume, and you need to test it before the volume shows up.
Today we start. We're disclosing the first 14 silent vulnerabilities processed through Athena: bugs already fixed at HEAD, some of them years ago, that never got a CVE and so never showed up in a scanner. All 14 are in Java projects: 1 critical, 1 high, 8 medium, and 4 low. The full list is in our public patch repository. If you're a Chainguard Libraries customer, remediated versions of every artifact are live in Chainguard Repository as of today.
We picked this batch on purpose. None of them is a live zero-day. Anyone could upgrade to a fixed version upstream. A few are still serious if you're running an affected version, and we walk through four below. But the reason to start here is that acting on these doesn't step on anyone else's process, which makes them the right place to run every step (patch, advisory, partner mitigation, shipped artifact) and find out what breaks before the thousands behind them arrive.
How disclosure works
Every finding enters Athena the same way: submitting members point frontier models at sandboxed applications and share what they find through Athena's secure portal. From there, one question decides where it goes. If the bug still exists at the latest version, disclosure runs through the Linux Foundation's Akrites initiative, and the maintainers ship the fix. If it's already fixed at HEAD and nobody said so, Chainguard drives the disclosure.
The Akrites path is slower by design, and it's starting to move. In the last few weeks, we've started to upstream five vulnerabilities through it. Five is a small number, but getting a critical fix landed upstream in an important package is what we needed to see: the process works end to end. We will have more to share about these zero-day vulnerabilities soon.
For the silent ones we're disclosing today, where the project has no path to accept a fix for the affected versions, we do three things.
We publish the patch. Plain patch files for every affected version, in a public GitHub repository, under the project's original license. Anyone can read what they are and apply them to their own build.
We publish the advisory. A free, public Chainguard VEX feed with the affected versions enumerated. Athena partners are plugged into it: shield partners are issuing non-patch mitigations, and surface partners can tell you when an affected dependency is in your stack.
We ship the fix. The patch is free. Applying it, rebuilding, signing, and generating an SBOM and SLSA L3 provenance is real work, and it's work most teams don't have time for on the day an advisory lands. The work that can prove to auditors that you’re running a safe version. Chainguard Libraries customers don't have to do it. Every artifact in today's batch has a remediated version in Chainguard Repository, published at the same moment as the advisory, so there's no window where you know about the bug and have nothing to deploy. Adopting it is a one-line change: swap the vulnerable artifact in your lockfile for Chainguard's version and rebuild. It carries the same package coordinates your application already uses, plus a Chainguard version qualifier (-0cgr.n
). No code changes, no major version upgrade. If a maintainer later adopts a backport we authored, we deprecate ours and point at upstream, so you always land on the canonical fix.
Expanding the coalition
An advisory only matters if someone downstream acts on it, so we're also growing the set of partners who do. Ten new shield and surface partners are joining Athena today, including AHEAD, Apiiro, Cloudsmith, HCLTech, Manifest Cyber, Oligo Security, Palo Alto Networks, ReversingLabs, Surf.ai, and Sysdig. Shield partners take Athena's vulnerability and patch data and turn it into non-patch mitigations (firewall rules, endpoint protections, application exploit blocking, traffic-level blocks) that protect you whether or not you've been able to swap in a fixed dependency. Surface partners tell you when you're running something vulnerable and how to fix it. Between them, they cover the distance between a fix existing and a fix being deployed.
Athena partners have already started to issue protections with the threat intelligence coming from Athena. The Akamai Security Intelligence Group tested the disclosed vulnerabilities against Akamai's security products and confirmed coverage for every WAF-applicable scenario with an actionable proof-of-concept exploit. Those protections are already live in App & API Protector and Kona Site Defender, so Akamai customers don't need to take any action. SIG is also watching for new variants and evasion techniques, so the defenses keep up as the exploits change.
"In an increasingly complex software supply chain, proactive industry collaboration is essential to staying ahead of emerging threats," said Dr. Boaz Gelbord, Chief Security Officer at Akamai. "By joining Chainguard's Athena Coalition as a Mitigation Partner, Akamai can leverage the community’s collective vulnerability intelligence to rigorously test and verify defenses before vulnerabilities can be exploited.”
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 that the vulnerable code gets wrong, one layer further out.
These are just some examples of what virtual patches can do. Every mitigation partner shrinks the window between knowing about a bug and being protected from it.
The first 14
All 14 were invisible to scanners until today because they had no identifier. Here are four, one across each severity level, picked to show the range of what a silent fix can hide.
Log in as anyone by removing the signature
CGP-xpq5-jm7p-884r
is a critical authentication bypass in io.jsonwebtoken:jjwt
, affecting versions >=0.1; <0.12.0. jjwt
is one of the most used Java libraries for JSON Web Tokens. A JWT is three base64url strings joined by dots: a header, a payload, and a signature. The header and payload are readable by anyone. The signature is the only part an attacker cannot produce without the server's key. The whole security model comes down to one question. Did the server check the third segment?
In the affected versions, the intention of the code is: “if there is a signature, check it.” The code does this instead: “if there is no signature, check nothing.” An attacker does not need to forge a signature. If the attacker deletes the signature and keeps the trailing dot, the result still looks like a well-formed three-part token, so the parser accepts it and skips the verification block. The claims come back as authentic, even when the application configured a verification key. The check that rejects alg: none
sits inside that same skipped block, so the guard written for this exact attack never runs. Any unauthenticated caller can present a token that claims to be any user, including an administrator.
The fix shipped in 0.12.0 inside a large JWE support PR. The only record of it is one line in the changelog and a JavaDoc note. A security fix inside a feature branch is invisible to anyone who does not read the diff. With no advisory and no CVE, no scanner could tell anyone on an affected version to move.
Remote code execution from a hostile login form
CGP-q285-qppx-f8fx
is a high-severity remote code execution in com.jayway.restassured:rest-assured
, affecting versions >=2.3.3; <5.3.0. REST-assured is the standard Java library for automated tests against web APIs. It runs on developer laptops and CI runners. Those are some of the most credential-rich machines an organization owns. Source code, signing keys, cloud tokens, and deployment credentials are all routinely available through the test process.
In the affected versions, a test can ask the library to find the CSRF field on a login form by itself. To do that, the library fetches the login page, reads the name of the first hidden input from the server's HTML, and pastes that name into a small query expression. The query expression is Groovy code. The library hands it to a full Groovy interpreter with no sandbox. The server under test controls the name attribute. A hostile or compromised server can return a name that closes the quote and appends statements of its own. One crafted login page is enough to run arbitrary commands inside the test run. REST-assured also permits plain HTTP, so an attacker on the network can inject the value without control of the server.
The fix shipped in 5.3.0 and removed the auto-detection step. The field name now comes from the test author's configuration, not from the response. The only record is one changelog line: "Added (much) improved support for CSRF tokens." There is no security wording, no advisory, and no CVE. Nobody on an affected version was told to move.
A random reset link that an attacker can reverse engineer
CGP-4qc2-x2g2-q32h
is a medium-severity use of a predictable random number generator in org.apache.commons:commons-lang3
, affecting versions >=3.0; <3.15.0. commons-lang3
is Apache's general-purpose utility library. Almost every Java project pulls it in, usually as a dependency of a dependency, and it sits underneath a very large share of all the Java software ever written. One of its helpers is RandomStringUtils
, and its most-used method is randomAlphanumeric()
. A developer who needs a random string to make a password reset link, a session identifier, a CSRF token, or an API key searches uses that method.
In the affected versions, every RandomStringUtils
method is backed by ThreadLocalRandom
. That generator is built for speed, not secrecy. It holds only 64 bits of internal state, and a handful of observed outputs is enough to reconstruct that state. An attacker who can collect a few tokens, for example, by requesting several password resets against their own account, can recover the generator's state. From there, the attacker can compute every token the generator has produced and every token it will produce, including the tokens issued to other users. Reset links can be forged, session identifiers can be guessed, and CSRF protection can be calculated instead of stolen.
The fix shipped in 3.15.0 (PR #1235) and changed the default. Starting in 3.15.0, the original methods are now backed by SecureRandom
, and the fast generator survives only behind an explicit insecure()
opt-in. No CVE and no GHSA were published, so nothing told anyone on an affected version that the tokens they had been issuing were predictable.
The config file that overflows the stack
CGP-3p49-8jjq-wc72
is a low-severity denial of service in commons-validator:commons-validator
, affecting versions >=1.1.0; <1.8.0. commons-validator
is Apache's library for input validation. Applications use it to check that a field holds a valid email address, date, credit card number, or URL, and to define validation rules in a validation.xml
file.
The defect sits in ValidatorUtils.replace(String value, String key, String replaceValue)
. The method calls itself once for each substitution it makes, and nothing bounds how deep it can go. A long enough value string drives the recursion until the thread runs out of stack, and the application fails with a StackOverflowError
. This one is hard to reach. The value string normally comes from the developer's own validation.xml
, not from a user. But a path that lets external input into that string turns a configuration file into a crash.
The fix is present from 1.8.0 onward. Neither the commit nor the release notes mentions this issue as a security bug or as any other kind of bug. This example is a case where a seemingly unrelated update can inadvertently address security issues, but in a way that is entirely invisible to consumers of the software.
None of these maintainers did anything wrong. They fixed the bug, which is the hard part. But a fix with no identifier is a fix only the attacker who reads the commit knows about, and a model can now go from that commit to a working exploit against every unfixed version in an afternoon. As of today, defenders have a copy too.
Fourteen is just the start
Fourteen findings against a backlog of more than 21,000 validated zero-days is a rounding error, and the ones behind them won't all be already-fixed bugs in old versions. The process gets faster from here. It doesn't change the underlying math, though: frontier models find these bugs faster than anyone can patch them, and the only real way out is software where these bug classes can't be written at all. Until that exists, the most useful thing a disclosure can do is arrive in a form that defenders can act on the same day. That's what today is.
Some things in your scanners will light up this week that were quiet last week. That's the system working. If you're a Chainguard Libraries customer, the remediated artifacts are already in Chainguard Repository: update your lockfile, rebuild, and the finding closes. If you're not, check the public patch repo.
If you maintain one of the affected projects and would rather own the backport yourself, we'd rather you did too. Write to cna@chainguard.dev, and we'll hand it over. If you'd like a heads-up before future disclosures that touch your project, tell us there as well.
And if you're pointing a frontier model at open source, sitting in front of traffic, or carrying fixes into customer environments, there's a role for you in Athena. Join us at chainguard.dev/athena.
Share this article
Related articles
- security
The flood is coming and the pipes were already full
- security
Athena spotlight: Black Duck on the importance of flagging zero-days at scale
- security
How financial services companies can modernize their software supply chain
- security
Proven, not promised: Chainguard Containers achieves SLSA Build Level 3
- security
The keyv and cacheable npm Supply Chain Attack: Inside the Mini Shai-Hulud Campaign
- security
Why AI-assisted attacks made software supply chain security its own category