Oracle Java JRE Unsupported Version Detection is a Critical Nessus finding (plugin 55958 on Windows, 64816 on Unix) meaning at least one Java runtime on the host is a release Oracle no longer supports, such as Java 7 or a non-LTS build. Fix it by moving to a supported release, uninstalling every older side-by-side JRE, and rescanning.
What the scanner is actually detecting
Tenable ships two plugins with the same finding title, one per platform family:
| Nessus plugin ID | Finding title | Family |
|---|---|---|
| 55958 | Oracle Java JRE Unsupported Version Detection | Windows |
| 64816 | Oracle Java JRE Unsupported Version Detection (Unix) | Misc. |
Both are local checks, so they only fire on credentialed scans or Nessus Agents. They consume the results of Tenable’s JRE detection plugins, which enumerate installed runtimes (on Windows through the registry) and, as Tenable notes, may include private JREs bundled with a JDK. Each runtime’s self-reported version is compared with Oracle’s Java SE support roadmap. Tenable states that the plugin does not flag versions still covered by Extended Support.
In practice that means the finding fires for:
- Java 7 and older (1.4, 5.0, 6, 7), which are past Extended Support.
- Non-LTS feature releases (9, 10, 12 to 16, 18 to 20, 22 to 24). Oracle treats each one as superseded the moment the next release ships, and none of them has Extended Support. Java 26’s Premier Support ends in September 2026, so expect it to join this list.
Java 8, 11, 17, 21 and 25 are LTS releases still inside Premier or Extended Support, so this plugin ignores them. An outdated update of one of those (for example an old Java 8 update) shows up under Tenable’s quarterly Critical Patch Update plugins instead.
Real-world risk
Tenable scores both plugins CVSS 10.0, which is its standard rating for unsupported software rather than a statement that a specific exploit exists for your host. The real problem is simple: an unsupported runtime will never receive another security fix, and every Java vulnerability Oracle patches from now on stays open on that host.
How much that matters depends on use. A JRE that runs a network-facing service or processes untrusted files is a genuine exposure. A forgotten Java 6 folder on a workstation is lower risk, especially since current browsers no longer load the Java plugin, but anything that finds it (a script, a file association, a user double-clicking a JAR) can still run it. Neither case improves with time.
How to confirm it on the host
Start with the plugin output, which lists each flagged path and version. Then check what Windows has registered. JRE 8 and earlier use Java Runtime Environment and Java Development Kit keys; Java 9 and later use JRE and JDK. 32-bit runtimes sit under WOW6432Node:
$keys = 'HKLM:SOFTWAREJavaSoftJava Runtime Environment',
'HKLM:SOFTWAREJavaSoftJava Development Kit',
'HKLM:SOFTWAREJavaSoftJRE',
'HKLM:SOFTWAREJavaSoftJDK',
'HKLM:SOFTWAREWOW6432NodeJavaSoftJava Runtime Environment',
'HKLM:SOFTWAREWOW6432NodeJavaSoftJRE'
Get-ChildItem $keys -ErrorAction SilentlyContinue |
ForEach-Object { [pscustomobject]@{ Version = $_.PSChildName; JavaHome = $_.GetValue('JavaHome') } }List everything Java-related in Programs and Features, including the product code you need for a silent uninstall:
Get-ItemProperty 'HKLM:SOFTWAREMicrosoftWindowsCurrentVersionUninstall*',
'HKLM:SOFTWAREWOW6432NodeMicrosoftWindowsCurrentVersionUninstall*' |
Where-Object { $_.DisplayName -match 'Java|J2SE|JDK|JRE' } |
Select-Object DisplayName, DisplayVersion, Publisher, PSChildNameFinally, look for copies the installer does not know about, then run each one to read its version:
Get-ChildItem 'C:Program FilesJava', 'C:Program Files (x86)Java' -Directory -ErrorAction SilentlyContinue
Get-ChildItem C: -Filter java.exe -Recurse -File -ErrorAction SilentlyContinue | Select-Object FullName
& 'C:Program FilesJavajre7binjava.exe' -versionThe recursive search is slow on large disks, but it is the only way to see JREs that applications ship inside their own folders.
How to fix it
Choose the target runtime
Move to a Java SE release that still receives updates: Java 8 under an Oracle subscription for commercial use, or an LTS release (11, 17, 21 or 25). A supported OpenJDK build such as Eclipse Temurin, Amazon Corretto or the Red Hat build of OpenJDK is equally valid. Pick the version the application vendor supports, not simply the newest.
Windows: remove old side-by-side versions
Oracle’s own documentation says that by default the JRE installer leaves all out-of-date Java versions on the system, which is why updating Java rarely closes this finding. Review the list first, then uninstall the old product codes silently:
$old = Get-ItemProperty 'HKLM:SOFTWAREMicrosoftWindowsCurrentVersionUninstall*',
'HKLM:SOFTWAREWOW6432NodeMicrosoftWindowsCurrentVersionUninstall*' |
Where-Object { $_.DisplayName -match '^(Java|J2SE)' -and $_.PSChildName -like '{*' }
$old | Select-Object DisplayName, DisplayVersion, PSChildName # review, then filter out the version you keep
foreach ($app in $old) {
Start-Process msiexec.exe -ArgumentList "/x $($app.PSChildName) /qn /norestart" -Wait
}On a single machine you can use Settings > Apps or Oracle’s Java Uninstall Tool instead.
Windows: Oracle JRE 8 with automatic cleanup
If you are staying on Oracle JRE 8, the offline EXE installer can remove out-of-date JREs as it installs. The option only works with a silent install and, per Oracle, removes JREs below the security baseline:
jre-8uNNN-windows-x64.exe /s REMOVEOUTOFDATEJRES=1It does not remove JDKs or non-Oracle runtimes, so run the inventory again afterwards.
Windows: replace Oracle JRE 8 with OpenJDK
Temurin’s MSI installs silently with the features you choose. This command, from Adoptium’s documentation, also sets JAVA_HOME:
msiexec /i <package>.msi ADDLOCAL=FeatureMain,FeatureEnvironment,FeatureJarFileRunWith,FeatureJavaHome INSTALLDIR="c:Program FilesTemurin" /quietUninstall the old Oracle JRE with the loop above, then point services and launchers at the new path.
Clean up stale folders and registry keys
If the plugin output still lists a path after the uninstall, check whether the folder or its JavaSoft subkey survived. Confirm nothing references the path, back up the key, then delete only the leftovers for that version:
reg export "HKLMSOFTWAREJavaSoft" C:Tempjavasoft-backup.reg
Remove-Item -LiteralPath 'HKLM:SOFTWAREJavaSoftJava Runtime Environment1.7.0_80' -Recurse
Remove-Item -LiteralPath 'C:Program FilesJavajre7' -Recurse -ForceApplication-bundled runtimes
When the flagged path sits inside a product’s own directory (backup agents, monitoring tools, older admin consoles), the fix is a vendor update that ships a newer runtime. Swapping the JRE folder yourself may break the product or its support terms, so ask the vendor first.
Linux and Unix hosts (plugin 64816)
Find every runtime, including ones outside PATH:
readlink -f "$(command -v java)"
rpm -qa | grep -iE 'jre|jdk|java' # RHEL, SUSE
dpkg -l | grep -iE 'jre|jdk|java' # Debian, Ubuntu
find / -xdev -type f -path '*/bin/java' 2>/dev/nullRemove old Oracle RPMs with sudo rpm -e <package> and delete tarball installs (for example under /opt) once no service or start script points to them. Then install a supported build, such as Red Hat’s documented package, and select it:
sudo yum install java-21-openjdk
sudo alternatives --config javaOn Debian and Ubuntu, install openjdk-21-jre-headless (or openjdk-17-jre-headless where your release does not ship 21) and run sudo update-alternatives --config java.
How to verify the fix and rescan
- Re-run the registry, uninstall-key and file searches above and confirm that no unsupported version remains.
- Run
java -versionas the service account that uses Java and confirm it resolves to the new runtime. - Rescan with the same credentialed policy. On Unix, Tenable’s detection plugin only finds JREs outside PATH or package managers when thorough tests are enabled, so turn that on for the verification scan.
Java findings tend to come back after reimaging, when a golden image still carries an old JRE, or when a new application quietly installs one. If you see that pattern, look at your vulnerability recurrence rate rather than treating each reopen as a new problem.
What can break and how to roll back
- Hardcoded paths: services, scheduled tasks and .bat launchers often call a versioned folder such as
jre1.8.0_202. For JRE 8u421 and later, Oracle creates aC:Program FilesJavalatestjre-1.8junction that survives updates; point applications there. - Java Web Start and applets: Oracle’s roadmap states that Java SE 11 and later do not include the deployment stack. JNLP applications will not run on 11+ or on most OpenJDK builds.
- Removed APIs: JEP 320 removed the Java EE and CORBA modules (JAXB, JAX-WS and others) in Java 11. Applications that relied on them fail at startup until they bundle those libraries.
- Bitness: 32-bit applications need a 32-bit runtime.
To roll back, reinstall the previous runtime from your software repository (keep the installers before you start) and restore JAVA_HOME or the service path. A rollback reopens the finding, so record a time-boxed exception and restrict the host’s exposure until the application is fixed.
Common false positive reasons
- Oracle support contracts: Tenable notes that a JRE covered under Oracle Lifetime Support may be a false positive. Keep the contract reference with the exception.
- Uninstall leftovers: a folder or JavaSoft subkey remaining after an uninstall can keep the finding open even though the runtime is not registered in Programs and Features.
- Vendor labeling: the detection is built around Oracle’s layout. Temurin’s optional FeatureOracleJavaSoft writes Oracle-style HKLM keys, so check the vendor of any flagged path before assuming it is an Oracle JRE.
- Stale results: agent or scan data collected before the cleanup. Rescan before disputing the finding.
FAQ
Does plugin 55958 flag Java 8?
No. Oracle lists Extended Support for Java 8 until December 2030, and the plugin skips versions under Extended Support. An outdated Java 8 update still triggers the quarterly patch plugins.
I installed the latest Java. Why is the finding still open?
The installer leaves older versions in place by default. Uninstall them explicitly or use REMOVEOUTOFDATEJRES=1, then rescan.
Can I replace Oracle JRE 8 with OpenJDK?
For most server and desktop applications, yes, and OpenJDK 8 builds exist if the application cannot move to 11 or later. The exception is anything depending on Java Web Start or the browser plugin.
Which LTS release should new deployments use?
The one your vendor certifies. Oracle notes that JDK 17 updates since October 2024, and JDK 21 updates from the October 2026 patch update, fall under the OTN license, while JDK 25 or later keeps the permissive license.
Tracking this finding across many hosts
Old JREs hide on long-lived servers and golden images, so it helps to track them per host. SITEY imports findings from 16 scanners, including Nessus results uploaded as .nessus exports, merges duplicates within each scanner, and supports per-finding retest for Nessus. Its AI can draft host-specific cleanup scripts that run through human approval before SITEY agents deploy them on Windows and Linux endpoints, followed by a retest to confirm closure.