Understanding Embedded Java Vulnerability Detection in Saner CVEM

Overview

Many users encounter confusion when Saner CVEM continues to report vulnerabilities related to Embedded Java, even after updating to the latest Java version or manually deploying the java.exe file on the endpoint.

This article aims to clarify how Saner CVEM detects embedded Java-related vulnerabilities, why simply pushing the latest java.exe from Patch Management may not resolve the detection, and what specific steps need to be followed to accurately remediate and close these findings.

How Saner CVEM Detects Embedded Java Vulnerabilities

Saner CVEM conducts a comprehensive process-level scan to detect vulnerabilities associated with java.exe, javaw.exe, or javaws.exe.

The detection process includes the following steps:

• Scanning the running processes of java.exe, javaw.exe or javaws.exe to locate all the instances of embedded Java, as multiple applications may have bundle this binary in their application.

• Extracting the version information embedded within each detected exe.

• Validating each version against known vulnerable version ranges, as defined by associated CVEs.

If any instance of java.exe, javaw.exe or javaws.exe is found to match a known vulnerable version, regardless of whether newer versions exist elsewhere on the system, the vulnerability will be flagged.

Why Saner CVEM Does Not Provide a Unified Patch (Vendor Link Instead)

Saner CVEM intentionally does not provide a direct patch for this vulnerability because:

• The Embedded Java vulnerability is not tied to a single application.

• Multiple applications on a system may use different versions of Java.

• There is no standardized or guaranteed upgrade path to replace all vulnerable instances.

• Even after upgrading an application, the vendor may continue to bundle an outdated version of Java.

• Java is a widely shared dynamic component, and its implementation and usage vary across vendors.

• Replacing shared binary across applications can break functionality if done without knowledge of the current build dependability on that version of Java.

Interpreting the Evidence View: Why You May See Non-Vulnerable Applications Listed?

A frequent source of confusion in Embedded Java vulnerability reports is the Evidence section in Saner CVEM. Users often report:

"Why does the Evidence view show applications with java.exe, javaw.exe or javaws.exe that are already up to date or not even part of the vulnerable version range? The report says the device is vulnerable, but the version I see looks fine!"

Here’s why this happens — and why it’s not incorrect.

What Saner CVEM’s Evidence View Shows

The Evidence section provides a list of all detected instances of the target file — in this case java.exe, javaw.exe or javaws.exe — across the entire device, regardless of version.

Each entry in the Evidence views shows:

• The full file path to the Java binary

• The version of that file

• The application context (if identifiable)

• Whether the version is within the vulnerable range or not

Why Non-Vulnerable Entries Appear

Saner CVEM intentionally displays both vulnerable and non-vulnerable instances in the Evidence view to provide full visibility. This supports:

1. Transparency: Full visibility into all known installations of Java binaries—not just the vulnerable ones.

2. Traceability: Helps validate which copies have been updated and which remain outdated.

However, only the instances of Java binary that fall within the vulnerable range actually trigger the vulnerability.

Summary:

• The Evidence tab may show multiple Java entries — but only one vulnerable file can trigger the report.

• Non-vulnerable versions are shown for reference only.

Example Scenario

CVE Applicable To:

• Java versions < 8u461

The Evidence tab will show both entries — however, the vulnerability is triggered by the second entry.

What This Means for You

• If you see applications in the Evidence list that are not in the vulnerable range, no action is required for those.

• Focus only on entries marked as vulnerable.

• Remediation is complete only when all vulnerable instances are fixed or removed, regardless of how many non-vulnerable ones exist.

How to Identify and Remediate Embedded Java Vulnerabilities

Step 1: Locate All Detected Instances

Navigate to:

Device > [Select Device] > Vulnerabilities > Evidence

Look for:

• File path (example: C:\Program Files (x86)\OldApp\java.exe)

• Version (example: 8u451)

• Detected CVE and affected version range

Document all vulnerable file paths.

Step 2: Determine the Application Source

For each detected Java instance:

• Identify which application installed or owns it.

• Check the vendor’s patch notes or advisory.

• Verify whether that Java file is being used by any installed program.

Step 3: Remediate

Depending on the situation:

    a) Update the Parent Application

    If the binary belongs to a known software product, update that product using the vendor's 

    latest supported build.

    b) Remove Obsolete or Unused Software

    Uninstall outdated or unused applications that still contain vulnerable embedded Java.

    c) Exclude False Positives (Use with Caution)

    If confirmed safe after internal validation, use Saner CVEM’s exclusion feature.

Note: Only do this if approved by your internal security/compliance team.