Dependencycheck: False positive on slf4j-api:1.8.0-beta2

[reddyalready]

False positive on library slf4j-api:1.8.0-beta2.jar - reported as cpe:/a:slf4j:slf4j:1.8.0.beta

<dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>slf4j-api</artifactId>
   <version>1.8.0-beta2</version>
</dependency>

The issue (CVE-2018-8088) has been resolved in 1.8.0-beta2, but dependency-check still flags the jar as vulnerable.

[jeremylong]

Thanks - this is a somewhat known issue in that the update versions (alpha, beta, milestone, etc.) are not properly analyzed and generally marked as exploitable.

[reddyalready]

Is it an issue with the cpe/regex matcher? Anything I can do to help?

[jeremylong]

This is deep in the CPE identification (specifically the CPEAnalyzer and Dependency objects). However, changes to the version numbers to better support alpha, beta, snapshot, m1, etc. could impact other parts of dependency-check-core. I will try and add this to an upcoming change to switch from the NVD XML data feeds to the NVD JSON data feed.

[dave-89]

According to the CVE entry and the Jira ticket, it seems that the vulnerable class is present in slf4j-ext, not in slf4j-api

[eyecats]

Noticing what dave-89 noticed above - EventData is not present in slf4j-api, nor does slf4j-api pull in slf4j-ext which contains EventData. I verified slf4j-ext is not being brought into our project, however, OWASP dependency-check-maven vulnerability scan is flagging slf4j-api anyways. Anyone have any ideas? (note: I'm on slf4j-api-1.7.25.jar).

log4j-over-slf4j-1.7.25.jar is also being flagged, and, doesn't pull in slf4j-ext as well.

[Aiko-Klostermann]

@reddyalready "The issue (CVE-2018-8088) has been resolved in 1.8.0-beta2"
We are currently having the same issue and want to upgrade to a newer version. We were searching for a source but couldn't find any changelog anywhere.

[pmehtacredify]

I see the same issue as @eyecats mentioned. Even though we don't use slf4j-ext, OWASP dep-check reports CVE-2018-8088 for following libraries: jcl-over-slf4j-1.7.25.jar, jul-to-slf4j-1.7.25.jar, log4j-over-slf4j-1.7.25.jar, slf4j-api-1.7.25.jar. Appears to be false positive, as others noted above. Please add a comment, if someone noticed anything different with respect to above libraries.

[isaki]

I am getting false positives as well on slf4j-api-1.7.25.jar (I've checked my dependencies, the ext jar is not pulled in anywhere). I looked at one of my shaded jars to confirm:

     3833  03-16-2017 16:53   META-INF/maven/org.slf4j/slf4j-api/pom.xml
      986  03-16-2017 16:53   META-INF/maven/org.slf4j/jul-to-slf4j/pom.xml
     1126  03-16-2017 16:53   META-INF/maven/org.slf4j/log4j-over-slf4j/pom.xml
      959  03-16-2017 16:53   META-INF/maven/org.slf4j/jcl-over-slf4j/pom.xml

[reddyalready]

@Aiko-Klostermann see https://nvd.nist.gov/vuln/detail/CVE-2018-8088, where it states the issue was resolved in beta2

[stepio]

@reddyalready

But your link says that issue was in slf4j-ext, while in this ticket slf4j-api is discussed.
So... What about marking the whole slf4j-api as false positive, not just 1.8.0-beta2 ?

[stepio]

@jeremylong

Forgive me if I'm wrong, but I created a PR to fix this - I see that this issue is here for quite a long time. I don't understand why slf4j-api is "punished" for slf4j-ext :)