CVE-2026-91403: Java trusted compromised eMudhra certificates

Why one trusted intermediate certificate opens the door to every domain

On every TLS connection, Java checks whether the server certificate chains up to a certificate authority it trusts. The trusted set included eight eMudhra intermediate certificates whose private keys were generated incorrectly. According to the OpenJDK advisory, they can be recovered in a fraction of a second. Anyone holding such a key can issue a certificate for any domain, and a Java application will accept it without any warning.

In practice, an attacker who can intercept traffic between your application and an external service can impersonate any HTTPS server. The application will send them API keys, tokens and data, and treat their responses as genuine. This covers calls to external APIs, integrations with partner systems and update checks.

Oracle issued an out-of-cycle alert and rates the flaw in the JSSE component at 9.1 in CVSS 3.1. Red Hat gives it 6.8, because it cannot be exploited without a man-in-the-middle position. That gap shows well that urgency depends on which networks your traffic crosses. Browsers blocked these certificates between 17 and 20 October, but the JDK has its own certificate store and needs a separate fix. The scheduled Java update (CPU) of 20 October does not resolve the issue: the versions released that day are on the affected list. eMudhra and researchers have found no evidence that the keys were misused, and the CVE is not in the CISA KEV catalog (as of 22 October 2026).

Who is really exposed

The most exposed are Java applications that open TLS connections themselves as a client, when that traffic crosses a network an attacker could influence: the public internet, shared networks, Wi-Fi used by laptops running Java tools, or a corporate network where someone has already gained a foothold. Less exposed are servers that only accept connections from browsers, because the browser checks the certificate in that case. The same goes for systems that talk only inside a closed internal network.

Affected versions

• Oracle Java SE: 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5, 27.0.1. Oracle notes that earlier versions are likely affected as well.
• Oracle GraalVM for JDK 17.0.21 and 21.0.13, and GraalVM Enterprise Edition 21.3.20.
• OpenJDK standalone installations (archive, installer, JDK bundled with an application or container image): 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.33, 8u512 and earlier.
• OpenJDK from OS packages (including Debian, Ubuntu, Red Hat Enterprise Linux, Fedora, Oracle Linux) uses the system certificate store, so updating the ca-certificates package is enough. FreeBSD and Homebrew builds must be updated directly.

The fixed build for your Java line is listed in the Patch Availability document referenced in the Oracle alert. Check it before you update.

Where Java hides beyond the application server

A single java -version on the main server is not enough. Java often lives in places nobody remembers.

1. Servers and workstations: run java -version and find out where Java comes from. An OS package shows up in dpkg -l | grep openjdk or rpm -qa | grep openjdk, and a pending certificate update in apt list --upgradable | grep ca-certificates or dnf check-update ca-certificates.
2. Application servers and vendor software with an embedded Java runtime. Each copy has its own certificate store. Find them with find / -path '*/bin/java' -type f 2>/dev/null. For vendor products, check whether an update is available.
3. Docker images: the FROM line in your Dockerfiles. An image with a bundled JDK will not update itself: it has to be rebuilt.
4. CI agents and build servers: the JDK version in your pipelines. Builds download dependencies over TLS, so the agent is a TLS client too.

The mvn dependency:tree and gradle dependencies commands will not show this problem, because it lies in the JDK itself.

Today and in the next maintenance window

Today

• On systems with distribution OpenJDK, update ca-certificates (apt upgrade ca-certificates or dnf upgrade ca-certificates) and restart your Java services so they load the new store.
• For applications with a standalone JDK that connect to services on the internet and cannot be updated yet, OpenJDK lists two workarounds. The first is replacing $JDK_HOME/lib/security/blocked.certs with the new version (in JDK 8 the file is called blacklisted.certs). The second is enabling revocation checking with -Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true. The second workaround changes the behaviour of every TLS connection, so test it before rolling it out to production.
• If in doubt, run the application with -Djava.security.debug=certpath and look for emSign or eMudhra in the certificate chains.

In the next maintenance window

• Update standalone Oracle JDK, GraalVM and OpenJDK installations to the fixed builds, rebuild container images and deploy updates from software vendors.
• In the same restart, deploy the October CPU: it contains 55 fixes for Java SE, with a highest score of 7.5.
• Signed JAR files (JDK 17 and later) can be verified with revocation checks: jarsigner -verify -revcheck -strict file.jar.

There is no evidence of key misuse, so hunting for a breach is not necessary.

A JDK inventory is the basis of a fast response

Browsers cut these certificates off within a few days, while in Java every copy of the JDK needs its own fix. A company with an inventory of all its Java installations, including those bundled with vendor software and container images, can deal with this in a single afternoon. For each one, record the version, the source (OS package, archive, image, vendor product) and the person responsible. Where possible, choose OpenJDK from distribution packages, because then the certificate store is updated together with the system.