[FP]: jfr.jar incorrectly mapped to Oracle JRockit CPE

[MohammedSuhaibT]

Package URl

pkg:generic/jfr

CPE

cpe:2.3:a:oracle:jrockit:1.8.0.471:*:*:*:*:*:*:*

CVE

No response

ODC Integration

None

ODC Version

12.1.9

Description

Multiple CVEs are being reported due to incorrect CPE matching of jfr.jar to Oracle JRockit.

The Dependency-Check report identifies the following CPE:
cpe:2.3:a:oracle:jrockit:1.8.0.471:::::::*

This mapping is incorrect.

The application is running on Oracle Java version 1.8.0_471 (HotSpot JVM), and not on Oracle JRockit.

The reported CVEs (CVE-2009-1006, CVE-2011-3545, CVE-2011-3551, CVE-2011-3553, CVE-2011-3556, CVE-2011-3557, CVE-2013-2380, CVE-2013-5780, CVE-2013-5782, CVE-2013-5797, CVE-2013-5802, CVE-2013-5803, CVE-2013-5804, CVE-2013-5823, CVE-2013-5825, CVE-2013-5830) apply to legacy JRockit and older Java versions, and do not affect the Java version used in our system.

The dependency jfr.jar (Java Flight Recorder) is part of standard Oracle/OpenJDK distributions and does not indicate usage of JRockit.

However, these CVEs are still being reported due to incorrect CPE mapping.

No vulnerable components are present and no exploitable code paths exist in the current application.

Hence, this is a false positive.

FP.csv

[chadlwilson]

Use the search, please.

https://github.com/search?q=repo%3Adependency-check%2FDependencyCheck+jrockit&type=issues

[MohammedSuhaibT]

Thanks for the pointer, @chadlwilson

We understand similar issues exist and that false positives can occur due to CPE matching.

In our case:

• jfr.jar is being mapped to Oracle JRockit CPE
• Our runtime is Java 1.8.0_471 (HotSpot), not JRockit
• This results in multiple JRockit-specific CVEs being reported

Could you please confirm the recommended way to handle this?

Specifically:

• Is suppression the expected approach for such cases?
• Or is there a way to refine the CPE matching to avoid this mapping?

Thanks.

[chadlwilson]

See #7818 (comment) and many others.

You are obviously trying to scan the jars inside a Java runtime via the CLI. Since these jars are part of your JDK, what do you hope to find by scanning these jars, which are part of your Java Runtime, with ODC?

Such jars are not published to Maven Central, and do not contain package metadata and so will not be able to be matched to a package reliably. We can't centrally suppress anything without a proper package URI. We also can't even think about changing code to reduce the chance of the false positive without the "evidence" collected from a report and reproduction steps being shared, and in my experience folks rarely do this -- or we can't do anything about it anyway -- so I don't usually bother anymore.

You should probably exclude jars inside a java runtime from your scan, or you'll have to manage the suppressions yourself if you decide to scan things like this.

[MohammedSuhaibT]

Hi @chadlwilson,

Please find the dependency report for your reference:
dependency-check-report.json

OWASP Dependency-Check v12.1.9 incorrectly identifies jfr.jar from a standard Oracle Java SE 1.8.0_471 HotSpot JVM installation as Oracle JRockit, producing the CPE cpe:2.3:a:oracle:jrockit:1.8.0.471 with LOW confidence. This results in 16 false positive CVEs (CVE-2009-1006, CVE-2011-3545, CVE-2011-3551, CVE-2011-3553, CVE-2011-3556, CVE-2011-3557, CVE-2013-2380, CVE-2013-5780, CVE-2013-5782, CVE-2013-5797, CVE-2013-5802, CVE-2013-5803, CVE-2013-5804, CVE-2013-5823, CVE-2013-5825, CVE-2013-5830), all of which target the legacy Oracle JRockit JVM — a completely separate product that was discontinued in 2014.

The misidentification occurs because jfr.jar contains internal classes under the oracle.jrockit.jfr package namespace. This package exists solely because Oracle ported the Java Flight Recorder feature from JRockit into HotSpot starting with Java 7u40, retaining the original package names. The jar's own manifest unambiguously identifies it as Java SE — "Implementation-Title: Java Runtime Environment, Implementation-Version: 1.8.0_471, Specification-Title: Java Platform API Specification" — all at HIGH/MEDIUM confidence. Despite this, the CPE analyzer allows a single LOW-confidence package name match (jrockit) to override these stronger signals and produce an incorrect JRockit CPE.

Proof Point:
Oracle JRockit used version strings in the format R27.x.x / R28.x.x, with the last release being R28.3.x. A JRockit version 1.8.0_471 never existed — this is clearly a Java SE version string. The generated CPE cpe:2.3:a:oracle:jrockit:1.8.0.471 represents a product-version combination that does not and cannot exist in the NVD database as a legitimate entry.

This jar (jfr.jar, SHA256:) ships with every standard Oracle JDK 8 installation and is located at $JAVA_HOME/jre/lib/jfr.jar. Any organization scanning JDK 8 jars for compliance will encounter this false positive.

Suggested Fix:
When a jar's manifest contains Implementation-Title matching Java Runtime Environment at HIGH confidence, the CPE analyzer should exclude oracle:jrockit from candidate CPEs, as JRockit's manifest would identify itself as Oracle JRockit, not Java Runtime Environment. Alternatively, this could be addressed by adding a built-in suppression rule for jfr.jar with known Oracle JDK 8 hashes mapped to the correct Java SE CPE.

[chadlwilson]

If I wanted an LLM to tell me the problem I'd ask it myself, thanks.

Your evidence indicates that you are renaming all of the jars that you are scanning. This will cause problems. If you rename artifacts that need scanning, with ODC as it currently is, you are taking ownership for them and you will likely get false positives. They are now your false positives to manage.

For example, jfr is now F72-jfr.jar. Note how the nMe and version signal is also detected incorrectly now. It will also break existing suppressions that manage some JDK jars. We cannot maintain the literally thousands of hashes for JDK jars.

{
    "isVirtual" : false,
    "fileName" : "F72-jfr.jar",
    "filePath" : "/tmp/src/jars/F72-jfr.jar",
    "md5" : "405bd1a090b61433cdb6d05218725fc5",
    "sha1" : "54751caf5d0c9d7599cdf058d0e45376a8741472",
    "sha256" : "0f6162b4bf6d8a887be35e47f72d2fab3ac0945beb8fea904e0a4d8bca036bf9",
    "evidenceCollected" : {
      "vendorEvidence" : [ {
        "type" : "vendor",
        "confidence" : "HIGH",
        "source" : "file",
        "name" : "name",
        "value" : "F72-jfr"
      }, {
        "type" : "vendor",
        "confidence" : "LOW",
        "source" : "jar",
        "name" : "package name",
        "value" : "jfr"
      }, {
        "type" : "vendor",
        "confidence" : "LOW",
        "source" : "jar",
        "name" : "package name",
        "value" : "jrockit"
      }, {
        "type" : "vendor",
        "confidence" : "HIGHEST",
        "source" : "jar",
        "name" : "package name",
        "value" : "oracle"
      }, {
        "type" : "vendor",
        "confidence" : "LOW",
        "source" : "jar",
        "name" : "package name",
        "value" : "oracle"
      }, {
        "type" : "vendor",
        "confidence" : "HIGHEST",
        "source" : "jar (hint)",
        "name" : "package name",
        "value" : "sun"
      }, {
        "type" : "vendor",
        "confidence" : "LOW",
        "source" : "jar (hint)",
        "name" : "package name",
        "value" : "sun"
      }, {
        "type" : "vendor",
        "confidence" : "HIGH",
        "source" : "Manifest",
        "name" : "Implementation-Vendor",
        "value" : "Oracle Corporation"
      }, {
        "type" : "vendor",
        "confidence" : "LOW",
        "source" : "Manifest",
        "name" : "specification-vendor",
        "value" : "Oracle Corporation"
      } ],
      "productEvidence" : [ {
        "type" : "product",
        "confidence" : "HIGH",
        "source" : "file",
        "name" : "name",
        "value" : "F72-jfr"
      }, {
        "type" : "product",
        "confidence" : "LOW",
        "source" : "jar",
        "name" : "package name",
        "value" : "jfr"
      }, {
        "type" : "product",
        "confidence" : "LOW",
        "source" : "jar",
        "name" : "package name",
        "value" : "jrockit"
      }, {
        "type" : "product",
        "confidence" : "HIGH",
        "source" : "Manifest",
        "name" : "Implementation-Title",
        "value" : "Java Runtime Environment"
      }, {
        "type" : "product",
        "confidence" : "MEDIUM",
        "source" : "Manifest",
        "name" : "specification-title",
        "value" : "Java Platform API Specification"
      } ],
      "versionEvidence" : [ {
        "type" : "version",
        "confidence" : "MEDIUM",
        "source" : "file",
        "name" : "name",
        "value" : "F72-jfr"
      }, {
        "type" : "version",
        "confidence" : "MEDIUM",
        "source" : "file",
        "name" : "version",
        "value" : "72"
      }, {
        "type" : "version",
        "confidence" : "HIGH",
        "source" : "Manifest",
        "name" : "Implementation-Version",
        "value" : "1.8.0_471"
      } ]
    },
    "vulnerabilityIds" : [ {
      "id" : "cpe:2.3:a:oracle:jrockit:1.8.0.471:*:*:*:*:*:*:*",
      "confidence" : "LOW"
    } ],

Personally I do not like the package detection the tie causing this false positive, but it has been there for a long time and this conversation is unlikely to get it changed.

Use the original filenames - or maintain suppressions from the file hash or filename to the CPE yourself please.