We took 94 recent critical-severity Java vulnerabilities and re-checked every GitHub advisory against the actual published Maven artifacts. 30 of them - almost one in three - carried wrong information: the wrong affected versions, the wrong fixed version, or the wrong package named entirely. And the volume of advisories you're meant to trust is climbing faster than ever.
We pulled 94 recent critical-severity Java vulnerabilities and compared each GitHub advisory against the actual published artifacts and sources. When the data is wrong, so is the scanner - this noise might seem negligible, but besides forcing you to upgrade dependencies for no reason, it widens your exposure to supply-chain attacks.
The advisory's vulnerable-version range didn't match reality. Scanners then flag builds that are actually safe, or stay silent on builds that are actually exposed.
The advisory named the wrong Maven artifact entirely - making users update the wrong thing and remaining vulnerable.
The version listed as "fixed" didn't actually contain the patch - or pointed at the wrong release. "Just upgrade to the fixed version" leaves you exposed.
The range had no lower bound, so it also matches versions outside the 9.x line. Older versions fell through the cracks despite having the information in the description of the advisory.
"… The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.0 through 8.5.100."
Due to the confusion of Jenkins plugins and Java dependencies, the advisory named the parent of the actual plugin as the vulnerable package.
:git ✗ the unrelated Git plugin — what the advisory named:github <parent>
<groupId>org.jenkins-ci.plugins</groupId> # the PARENT pom - not the artifact
<artifactId>plugin</artifactId>
<version>5.28</version>
</parent>
# the package's real coordinates
<groupId>com.coravy.hudson.plugins.github</groupId>
<artifactId>github</artifactId>
<version>1.46.0.1</version>
The advisory marks this deserialization RCE fixed in 4.0.0 - but that version only
added an opt-in allow-list while still deserializing attacker-controlled values
by default. The vulnerable handler wasn't removed until 4.1.0.
public Object getAttribute(final String name) {
- return ProfileHelper.getInternalAttributeHandler().restore(this.attributes.get(name)); # performs deserialization
+ return this.attributes.get(name);
}
The accuracy problem is getting bigger because the pile is getting bigger. In the first half of 2026 alone, GitHub filed roughly 6,900 reviewed advisories - already nearly double all of 2025.
Advisories filed each quarter.
Source: GitHub Advisory Database.
We don't take advisory metadata at face value. Seal re-checks the affected package, the vulnerable-version range, and the fixed version against the real artifacts - then ships a verified, tested patch. As we showed in our previous research, the standard disclosure process is already too slow for the age of agentic exploitation - and now the data itself can't be trusted as-is.
Seal is a CVE Numbering Authority (CNA). When we publish a vulnerability, we set the affected and fixed version ranges ourselves - verified against the real artifacts - so the advisory is accurate at the source, not corrected after the fact.
Affected coordinate, vulnerable-version range, and fixed version - all verified against the actual published Maven artifacts and source, not just the advisory's metadata.
Wrong version ranges, wrong fixed versions, and misattributed packages get corrected - so your scanner alerts on what's actually vulnerable and stays quiet on what isn't.
For affected and out-of-support versions, Seal publishes a version-compatible patched build that installs through Seal's CLI. No code changes required.
We'll cross-check your Maven dependencies against verified vulnerability data and flag any advisories with wrong affected versions, wrong fixed versions, or misattributed packages. We'll reach out with findings.
The advisory's facts don't match the real software. In our audit that took three forms: the wrong affected version range (safe builds get flagged or vulnerable builds get missed), the wrong fixed version ("just upgrade" leaves you exposed), or the wrong Maven package named entirely (the named coordinate isn't the one carrying the vulnerable code).
We re-checked 94 recent critical-severity Java (Maven) vulnerability advisories against the actual published artifacts. 30 - about 32%, nearly one in three - carried at least one factual error.
GitHub's reviewed advisory volume is surging - the first half of 2026 already saw roughly 6,900 advisories, nearly double all of 2025. These are new CVEs being disclosed now, not older ones being re-filed.
Seal re-verifies the affected coordinate, the vulnerable-version range, and the fixed version against the real artifacts, corrects what's wrong, and ships a verified, tested patch. For affected and out-of-support versions, Seal publishes a drop-in patched build that installs through Seal's CLI with no code changes.
Seal re-verifies vulnerability advisories against the real artifacts and ships tested patches - so you're not chasing false positives or shipping versions that were never really fixed. Scan your dependencies and see what's covered.