[FP]: log4j-api is not log4j core

[vmj]

Package URl

pkg:maven/org.apache.logging.log4j/log4j-api@2.24.3

CPE

cpe:2.3:a:apache:log4j:2.24.3:::::::*

CVE

CVE-2025-68161

ODC Integration

{"label" => "Gradle Plugin"}

ODC Version

12.2.0

Description

As far as I can tell, the vulnerability is in log4j core. Shipping log4j-api does not imply that core is included, too.

[github-actions]

Maven Coordinates

<dependency>
   <groupId>org.apache.logging.log4j</groupId>
   <artifactId>log4j-api</artifactId>
   <version>2.24.3</version>
</dependency>

Suppression rule:

<suppress base="true">
   <notes><![CDATA[
   FP per issue #8228
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/org\.apache\.logging\.log4j/log4j-api@.*$</packageUrl>
   <cpe>cpe:/a:apache:log4j</cpe>
</suppress>

Link to test results: https://github.com/dependency-check/DependencyCheck/actions/runs/20995186945

[github-actions]

Maven Coordinates

<dependency>
   <groupId>org.apache.logging.log4j</groupId>
   <artifactId>log4j-api</artifactId>
   <version>2.24.3</version>
</dependency>

Suppression rule:

<suppress base="true">
   <notes><![CDATA[
   FP per issue #8228
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/org\.apache\.logging\.log4j/log4j-api@.*$</packageUrl>
   <cpe>cpe:/a:apache:log4j</cpe>
</suppress>

Link to test results: https://github.com/dependency-check/DependencyCheck/actions/runs/20995209150

[chadlwilson]

Yes the API and the core are different.

However there are not separate product identifiers (CPE) for the API vs core, so unfortunately with NVD data there's nothing we can do about this. They do not track vulnerabilities at individual jar/library level in most cases, even if the upstream data at GHSA does.

If we suppressed this here we'd risk any future vulnerability in the API jar being suppressed. Even if that is unlikely given the nature of most API jars that's not a maintenance overhead this project can take (knowing which libraries do this or that over time).

Previous practice in this project is not to make this decision on users behalf, and not to manage suppressions at a CVE-by-CVE level - so you'll have to manage this yourself (or just upgrade the API jar since they always version them together to my knowledge)

[chadlwilson]

The better long term solution (personal opinion) is to move away from NVD data entirely and use GHSA, osv.dev etc - while allowing NVD to be disabled (or ignored for data beyond a certain date,.or where a CBE can be attributed more specifically by better data).

However NVD is baked very solidly into this tool's core, and it has limited contributors so I am unsure when/if that will happen, and I imagine many folks who dislike NVD data will have already moved to a different tool already.

[vmj]

@chadlwilson ok, I understand. Thank you for the explanation!

[profhenry]

Would it be possible to add the following suppression instead

<suppress>
	<notes><![CDATA[
	file name: log4j-api-2.24.3.jar
	]]></notes>
	<packageUrl regex="true">^pkg:maven/org\.apache\.logging\.log4j/log4j-api@.*$</packageUrl>
	<cve>CVE-2025-68161</cve>
</suppress>

[chadlwilson]

You can maintain that in your own suppressions file if you feel it is appropriate.

As I already said above, this project does not have the capacity to review and maintain CVE-by-CVE suppressions over time. We only do so in very limited cases where the design of ODC is the problem rather than the weaknesses of upstream data sources.