Repository navigation
dependency-check-maven fails to identify CVE-2026-89425 #8840
Copy link
Copy link
Closed as not planned
Description
CVE-2026-89425 affects tools.jackson.core:jackson-core 3.0.0-3.1.6, so given a simple project with dependency tools.jackson.core:jackson-core:jar:3.1.2 I'd expect it to flag CVE-2026-89425 - but no.
Take this (trivial) project that depends on the vulnerable version of jackson-core and a vulnerable version of log4j-core to validate that CVE's can be found:
<project
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.me</groupId>
<artifactId>jackson-cve-reproducer</artifactId>
<version>0.1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>tools.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
<version>3.1.2</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.25.4</version>
</dependency>
</dependencies>
</project>
But when scanned:
% mvn org.owasp:dependency-check-maven:13.0.0:aggregate -Dformats=JSON -DprettyPrint=true
{...}
[INFO] --- dependency-check:13.0.0:aggregate (default-cli) @ jackson-cve-reproducer ---
[INFO] Loaded 74 auto-discovered prefixes for remote repository apache.snapshots (prefixes-apache.snapshots.txt)
[WARNING] Could not transfer metadata /.meta/prefixes.txt from/to jvnet-nexus-releases (https://maven.java.net/content/repositories/releases/): (certificate_unknown) PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
[INFO] Checking for updates
[INFO] Skipping the NVD API Update as it was completed within the last 240 minutes
[INFO] Should skip RetireJSDataSource update since last update was within period PT24H.
[INFO] Should skip HostedSuppressionsDataSource update since last update was within period PT2H.
[INFO] Skipping Known Exploited Vulnerabilities update check since last check was within 24 hours.
[INFO] Check for updates complete (11 ms)
[INFO]
Dependency-Check is an open source tool performing a best effort analysis of 3rd party dependencies; false positives and false negatives may exist in the analysis performed by the tool. Use of the tool and the reporting provided constitutes acceptance for use in an AS IS condition, and there are NO warranties, implied or otherwise, with regard to the analysis or its use. Any use of the tool and the reporting provided is at the user's risk. In no event shall the copyright holder or OWASP be held liable for any damages whatsoever arising out of or in connection with the use of this tool, the analysis performed, or the resulting report.
About ODC: https://dependency-check.github.io/DependencyCheck/general/internals.html
False Positives: https://dependency-check.github.io/DependencyCheck/general/suppression.html
[INFO] Analysis Started
[INFO] Finished Archive Analyzer (0 seconds)
[INFO] Finished File Name Analyzer (0 seconds)
[INFO] Finished Jar Analyzer (0 seconds)
[INFO] Finished Dependency Merging Analyzer (0 seconds)
[INFO] Finished Hint Analyzer (0 seconds)
[INFO] Finished Version Filter Analyzer (0 seconds)
[INFO] Created CPE Index (0 seconds)
[INFO] Finished CPE Analyzer (0 seconds)
[INFO] Finished False Positive Analyzer (0 seconds)
[INFO] Finished NVD CVE Analyzer (0 seconds)
[WARNING] Sonatype OSS Index Analyzer disabled due to missing credentials. Authentication with token is now required, and OSS Index is migrating to Sonatype Guide. See https://dependency-check.github.io/DependencyCheck/analyzers/oss-index-analyzer.html for more information on authentication with Sonatype Guide OSS Index.
[INFO] Finished Vulnerability Suppression Analyzer (0 seconds)
[INFO] Finished Known Exploited Vulnerability Analyzer (0 seconds)
[INFO] Finished Dependency Bundling Analyzer (0 seconds)
[INFO] Finished Unused Suppression Rule Analyzer (0 seconds)
[INFO] Analysis Complete (1 seconds)
[INFO] Writing JSON report to: /Users/jgreen/Desktop/jackson-cve/target/dependency-check-report.json
[WARNING]
One or more dependencies were identified with known vulnerabilities in jackson-cve-reproducer:
log4j-core-2.25.4.jar (pkg:maven/org.apache.logging.log4j/log4j-core@2.25.4, cpe:2.3:a:apache:log4j:2.25.4:*:*:*:*:*:*:*) : CVE-2026-49844
See the dependency-check report for more details.
Note how it flagged the log4j-core CVE, but not CVE-2026-89425.
dependency-check-report.json report.
Of note - when comparing the NVD API response for CVE-2026-49844 vs CVE-2026-89425, I note CVE-2026-89425 - the problematic one - is missing the packageURL.
Reactions are currently unavailable
Activity
chadlwilson commentedon Oct 13, 2026
ODC can only match NVD CVEs that are enriched with CPE information from NVD. This is entirely expected and always the behaviour.
NVD is not enriching most CVEs now so you need to augment with other data sources such as Sonatype Guide or you'll miss a lot of stuff.
As.to whether ODC could change it's logic to also match based on
affectedpackage information (this info is newer to NVD), thats a separate enhancement that would require analysis of the API and datafeed results to see if it's possible, as well as its own heuristics for matching the vendor, product etc in absence of purls, and its own suppression logic.JackPGreen commentedon Oct 14, 2026
@chadlwilson thank you for the clarification!
chadlwilson commentedon Oct 14, 2026
If you would like to open an enhancement issue with some example CVEs about “support matching NVD vulnerabilities based on upstream “affected” CVE information (not just CPE) on NVd feed” that’d be helpful. Theoretically I think we could match on that right now, and get much better results, even if the PURL isn’t there.
I’m not sure which CVSS score would flow through though, as usually that means NVd haven’t scored it, so only CISA or the CNA. So we’d need to check its useful. And we’d need to check the same info comes through the data feeds, not just raw API calls.
chadlwilson commentedon Oct 14, 2026
https://nvd.nist.gov/vuln/detail/cve-2026-89425 Is a particularly weird example because the CNA is HeroDevs and only scored by them. For Jackson usually these would come through GHSA (maintainer security advisories) and be scored by Jackson itself, or the vulnerability researcher.
Right now ODC also has no way to convey scores at different levels of trust or to configure which one you want to see. It’s designed for the old world where NVD independently scored everything, not for the new world where for many projects the maintainer score is the most trustworthy, but also where vuln researchers and their LLM bots are “CNA shopping” and DOSing the underlying orgs to get CVEs raised directly with whatever inflated score they feel is good for their resume (VulnCheck and MITRE most guilty IMHO).
From a user perspective I’d prefer to have a configurable setting for this (CVSS source preference order, CVSS selection “highest” vs “lowest” vs “ordered preference” etc) if we are to extend using NVD as a conduit for information from the CNA or CVE.org that is not reviewed/enriched/scored by NVD or CISA.
JackPGreen commentedon Oct 14, 2026
👍
#8845
I share your concern but I think this is a separate issue. Hopefully there would still be value in fixing #8845 in isolation - this is a purely techncial challenge, vs the user-facing design changes required for "ranking".
chadlwilson commentedon Oct 14, 2026
Its somewhat separate but related, because right now no such scores are likely to be surfaced since CPE data is usually added at the same time as an "official" score by the same NVD analyst. At least historically that was true up until 2025/2026 when they started falling behind.
Once we start using subjective score data not provided by NVD for matching it may surface scores without displaying origin which might affect quality and trustworthiness of matches, which could be a qualitative loss of quality of results. Itd look like it came from NVD when really it did not, they were just the distributor. So need to at least consider the display of scores.