The October 2026 OpenJDK security review needs to cover both the quarterly patches and the eMudhra certificate trust issue. Windows and Linux can both be affected. Inventory the Java used by applications, development tools, bundled products, and containers, as well as the default Java in your terminal.
This article uses official advisories checked on October 26, 2026. The commands are examples for different installation methods; some Linux inspection steps were verified in a separate Ubuntu container. The Windows commands and production update and restart procedures are based on documentation, rather than execution on production systems.
On this page
What the recent OpenJDK CVEs cover
OpenJDK is an open source implementation of the Java runtime and development tools. A JDK includes development tools; a JRE provides the runtime. A CVE identifies a vulnerability or exposure, while CVSS measures severity. A score does not establish whether a particular system has been compromised.
Separate these three advisories when planning the work.
| Advisory | Issue to check | Remediation decision |
|---|---|---|
| October 20 quarterly update | Multiple CVEs in networking, image processing, XML, security, and other components | Apply the distribution vendor’s quarterly fixes |
| October 21, CVE-2026-91403 | Trust in affected eMudhra intermediate CA certificates; OpenJDK CVSS 3.1 score 9.1 | Verify the distrust update and the truststore actually used |
| October 24, CVE-2026-114820 | Additional emergency updates removing associated root CA certificates; Oracle CVSS 3.1 score 9.1 | Check the additional advisory even after the earlier update |
The sources are the October 20 OpenJDK advisory, October 21 OpenJDK advisory, and October 24 Oracle security alert. Oracle lists 55 Java SE security patches in its quarterly advisory. That is not a universal CVE count for every OpenJDK distribution. Read the product, version, and applicability notes in the October Oracle CPU.
Impact includes Java clients making HTTPS connections
A certificate authority, or CA, forms part of the chain used to decide whether a peer’s certificate is trusted. The eMudhra issue followed the compromise of private keys for eight intermediate CA certificates, enabling attackers to create fraudulent certificates. A Java application that continues to trust an affected chain could establish TLS communication with an impersonated endpoint. The Oracle eMudhra guidance and Red Hat security bulletin explain the background and attack conditions.
The principal impacts of this certificate issue are endpoint impersonation and loss of data confidentiality or integrity. An attacker needs conditions that allow interception or manipulation of the connection. The presence of Java alone does not demonstrate remote code execution or a compromise.
The following priorities are operational judgments based on the conditions described in those advisories.
| System | Reason to prioritize it | What to inspect |
|---|---|---|
| Java services calling external APIs or HTTPS endpoints | They may accept an affected certificate chain | Running JVM, truststore, outbound connection path |
| CI controllers, agents, and artifact download jobs | They access external files and delivery paths | Java on each controller and agent, signature verification |
| Products with bundled Java | Their patch path can differ from the OS default | Product advisories and bundled JRE location |
| Developer machines and containers | ZIP installations and image contents are easily missed | IDE runtime settings, images, stopped workloads |
An internal server can still need attention if it calls external repositories or APIs. Renewing a certificate on a reverse proxy or web server does not update a Java client’s truststore.
Reading affected versions and fixed builds
The following are versions explicitly listed as affected, not versions to install. Earlier releases may also be affected. Distribution backports and the actual truststore state must be checked separately.
| Release family | OpenJDK October 21 affected version | Oracle October 24 affected version |
|---|---|---|
| 8 | 8u504 and earlier | 8u511-b32 |
| 11 | 11.0.32.1 and earlier | 11.0.33.0.2 |
| 17 | 17.0.21 and earlier | 17.0.21.0.2 |
| 21 | 21.0.13 and earlier | 21.0.13.0.2 |
| 25 | 25.0.5 and earlier | 25.0.5.0.2 |
| 27 | 27.0.1 and earlier | 27.0.1.0.2 |
The columns describe different distributions and disclosure stages. Do not translate OpenJDK 8 update numbers directly into Oracle JDK 8 numbers. The separate October 21 Oracle alert also shows why additional updates followed the quarterly release.
For a standalone OpenJDK installation, check whether the vendor’s release notes include CVE-2026-114820 or JDK-8395690. This is the criterion given in the consolidated OpenJDK guidance. A label such as “21.0.13 or later” or “latest October build” is insufficient. For OS packages, compare the full package release with the distribution’s advisory. For bundled Java, use the product vendor’s supported update.
Finding Java installations on Windows
Default Java and running processes
In PowerShell, inspect Java for the current account. If Java cannot be found, skip the version command and inspect installation folders and service settings.
Get-Command java -All -ErrorAction SilentlyContinue |
Select-Object Source
where.exe java
$env:JAVA_HOME
java -XshowSettings:properties -version 2>&1Record java.home, java.vendor, and java.runtime.version. JAVA_HOME is an environment variable; it does not prove which Java a service uses. Windows Update and changes to the Windows certificate store do not establish that a standalone JDK’s cacerts was updated.
Use an administrator PowerShell session to inspect running Java processes and candidate services.
Get-CimInstance Win32_Process |
Where-Object { $_.Name -in @('java.exe', 'javaw.exe') } |
Select-Object ProcessId, Name, ExecutablePath, CommandLine
Get-CimInstance Win32_Service |
Where-Object { $_.PathName -match 'java|tomcat|jenkins|elastic' } |
Select-Object Name, State, ProcessId, PathNameIf ExecutablePath differs from the default Java location, track that installation separately. The service filter only identifies candidates. Compare it with your application service inventory because some service wrappers have no Java-related name, and inspect the wrapper’s JVM path or jvm.dll setting. Property definitions are documented in Microsoft’s Win32_Process and Win32_Service references.
ZIP installations and bundled JREs
These search roots are examples. Narrow them to the actual product directories, and also inspect developer tools in user profiles, scheduled tasks, and IDE runtime settings.
$roots = @('C:\Program Files', 'C:\Program Files (x86)', 'C:\apps')
Get-ChildItem -Path $roots -Filter java.exe -File -Recurse `
-ErrorAction SilentlyContinue |
Select-Object FullNameA file search cannot identify every embedded JVM. Products that load jvm.dll directly or use another runtime directory require a configuration review. Process command lines can contain passwords or tokens; redact those values before sharing results.
Finding Linux packages and service JVMs
Default executable and installed packages
Start with the following command. An empty result does not rule out manual installations under locations such as /opt, or Java inside containers.
command -v javaIf Java is found, inspect the resolved executable and runtime properties.
readlink -f "$(command -v java)"
java -XshowSettings:properties -version 2>&1On RHEL and Rocky Linux systems, record complete RPM package versions and releases.
rpm -qa 'java*openjdk*' 'ca-certificates*'On Ubuntu and Debian systems, inspect the package list and alternative executable paths.
dpkg-query -W -f='${binary:Package}\t${Version}\n' \
'openjdk-*' ca-certificates ca-certificates-java
update-alternatives --list javaCheck the actual installation state if the package query includes uninstalled entries or reports missing names. A backport adds fixes to an existing package version. Compare the distribution’s fixed package release instead of declaring it vulnerable solely from the upstream version string. Red Hat’s CVE entry discusses backports and distribution-specific behavior.
Running services and manual installations
Replace myapp.service and PID 1234 with the real service and process. Both Environment and the command line may contain sensitive configuration.
pgrep -a java
systemctl show myapp.service -p MainPID -p ExecStart -p Environment
sudo readlink /proc/1234/exe
sudo cat /proc/1234/cmdline | tr '\0' '\n'After an update, an executable link pointing to an old path or a file marked (deleted) warrants checking for an old process. A wrapper that loads the JVM directly may not have a Java executable name. Inspect the product configuration and its loaded libjvm.so path in that case.
sudo find /opt /usr/local /srv -type f \
\( -name java -o -name libjvm.so \) -print 2>/dev/nullInspect paths outside these search roots, mounted volumes, and stopped containers separately. Keep one inventory row per Java installation with its path, vendor, full version, service, and truststore.
Checking the certificate truststore
A truststore contains CA certificates that Java trusts. Typical defaults are lib/security/cacerts for JDK 11 and later and jre/lib/security/cacerts for JDK 8. An application can instead use -Djavax.net.ssl.trustStore=..., jssecacerts, or a custom TrustManager. Check the selection rules in the official JSSE guide.
The Oracle guidance links to CheckCerts.java, a program that checks for the relevant roots. Download the source from the official address, review it, and compile and run it with the JDK being inspected. These examples work with JDK 8 and later and assume the source file is in the current directory.
On Linux, replace /opt/jdk with the target JDK’s real path.
/opt/jdk/bin/javac CheckCerts.java
/opt/jdk/bin/java -cp . CheckCertsOn Windows, replace C:\apps\jdk with the target path.
& 'C:\apps\jdk\bin\javac.exe' .\CheckCerts.java
& 'C:\apps\jdk\bin\java.exe' -cp . CheckCertsBAD ROOT: means a relevant root remains in the default trusted issuer list being checked; the program exits with status 1. No bad root certificates found means none was found within that check’s scope. The program does not determine whether an intermediate-certificate blocklist patch is present or whether every CVE is resolved.
The source checks two roots associated with the compromised intermediates and two other eMudhra roots. In a separate Ubuntu 24.04 container, emSign Root CA - G1 was reported as BAD ROOT both before and after regenerating the Java store with the CA packages installed. Compare this output with the vendor’s intended distrust scope and actual store instead of treating it alone as proof that a specific CVE remains unfixed.
The program inspects the default TrustManager in a new JVM. It does not automatically inspect a service’s separate truststore, custom certificate validation, or the state of an already running JVM. If a JRE-only installation has no javac, compile with a compatible JDK and run using the target JRE, or use the vendor’s inspection tools.
Remediation on Windows
Apply a fixed build from the installed vendor within the Java release family supported by the product. Moving from Java 8 to 21 is a separate compatibility change. For bundled JREs, use the product vendor’s patch or supported procedure instead of overwriting files arbitrarily.
The following example is for Temurin 21 managed through WinGet. Check that the offered build’s release notes cover the certificate fix before upgrading. Use the appropriate package ID for another vendor or Java family.
winget list --id EclipseAdoptium.Temurin.21.JDK --exact
winget show --id EclipseAdoptium.Temurin.21.JDK --exact
winget upgrade --id EclipseAdoptium.Temurin.21.JDK --exactSee the Adoptium installation guide and release downloads. Availability can vary by OS and CPU architecture. No update appearing in WinGet is not evidence of safety. Check and replace MSI and ZIP installations individually with official fixed builds.
Before changing anything, preserve service settings, JVM options, custom CA certificates, and truststores. Configure services to use the new installation and restart during an approved maintenance window. In a new PowerShell session, compare the default Java with the executable path and version used by the actual service.
Remediation on Linux
RHEL and Rocky Linux
The following commands refresh repository metadata and inspect security advisory information. Assess Rocky Linux packages against Rocky repositories and advisories; do not assume a RHEL RHSA package number applies unchanged.
sudo dnf makecache --refresh
dnf updateinfo list --security
dnf list --installed 'java*openjdk*' ca-certificatesThis example updates an already installed Java 21 package family. Substitute the installed family and package names, review the proposed transaction, and update each installed family.
sudo dnf upgrade --refresh ca-certificates 'java-21-openjdk*'Red Hat explains that standard RHEL OpenJDK RPMs use the OS ca-certificates store by default. Portable Windows and Linux builds contain their own stores. Check Red Hat CVE-2026-91403 and the separate CA store advisory. Updating CAs alone does not fix the other quarterly CVEs.
Ubuntu and Debian
This example updates an already installed OpenJDK 21 runtime package. If you use a JDK or another family, substitute package names from the installation inventory. Confirm the supported repository and fixed package release first.
sudo apt update
apt-cache policy openjdk-21-jre-headless ca-certificates ca-certificates-java
sudo apt install --only-upgrade \
openjdk-21-jre-headless ca-certificates ca-certificates-javaThis incident needs an additional check. Ubuntu and OpenJDK explain that a synchronization issue in ca-certificates-java can prevent package updates alone from removing the relevant certificates from the Java store. They provide a workaround to regenerate the OS-managed Java keystore. Recheck the Ubuntu guidance before applying it.
The following procedure applies only when /etc/ssl/certs/java/cacerts is the relevant OS-managed Java store. Private CAs added only to that store can disappear during regeneration. Preserve the store and custom CA certificates, and establish how to restore or re-register them. Confirm that this backup succeeds before proceeding to the next block.
backup_dir="/root/java-ca-backup-$(date +%Y%m%d-%H%M%S)"
sudo install -d -m 700 "$backup_dir"
sudo cp -aL /etc/ssl/certs/java/cacerts "$backup_dir/cacerts"Then remove and regenerate the OS Java keystore.
sudo rm -f /etc/ssl/certs/java/cacerts
sudo update-ca-certificates --freshConfirm successful regeneration and the presence of required private CAs before restarting services. Do not apply this path blindly to a JDK unpacked from a ZIP or tar archive or to an application-specific truststore.
If a fixed build is not yet available
Official interim options for standalone JDKs include removing the relevant root CAs or enabling certificate revocation checking. Apply the OpenJDK guidance and Oracle procedure for the particular distribution and store. Aliases can vary, so avoid deleting entries with a keytool from an unrelated installation.
Removing a root can also affect legitimate endpoints. Back up the actual store and identify the vendor-specified certificates and aliases first. Revocation checking requires a review of CRL and OCSP reachability, failure handling, and application validation behavior. Adding flags alone is not a sufficient completion criterion.
Disabling TLS certificate validation or hostname verification is not remediation. If a connection fails after the patch, investigate the peer’s chain and a valid trust path rather than restoring a removed root without justification.
Containers and verification after restart
Updating Java on the host may leave the Java and CA stores inside images unchanged. Replace my-java-app with the real container name. If a product does not place Java on PATH, use its Dockerfile and documentation to identify the executable.
docker inspect --format '{{.Config.Image}} {{.Image}}' my-java-app
docker exec my-java-app java -XshowSettings:properties -versionRebuild and deploy using fixed base images and packages. Check any CA files copied into the image and truststores mounted from volumes. Manual changes inside a running container can disappear on the next deployment.
Verify the actual service state after the installer finishes.
- Record the Java path, vendor, full version, and service for every managed installation.
- Verify both quarterly CVE fixes and the additional October certificate actions against vendor advisories.
- Include default and custom truststores, containers, and bundled Java.
- Confirm that the restarted service JVM uses the fixed installation.
- Test external API, repository, and database TLS connections and application functions.
- Retain the check time, fixed package or image identifier, restart result, and recheck evidence.
For a running HotSpot JVM, a compatible JDK’s jcmd can also report VM.version and VM.system_properties. Use the process owner’s account and required permissions; inspect containerized JVMs within the appropriate namespace. The jcmd reference documents these requirements.
Start with one Java installation actually used by a service and record its vendor, full version, and truststore. Complete remediation, restart, and application connection checks for that entry, then repeat for the remaining installations.
