CVE-2026-91403: Java JSSE Certificate-Trust Vulnerability — eMudhra Intermediate CA Explained

Fig 1. CVE-2026-91403 — Oracle Java SE, GraalVM & OpenJDK JSSE certificate-trust vulnerability (CVSS 9.1).

On October 21, 2026, Oracle issued an out-of-band Security Alert for CVE-2026-91403 — a critical (CVSS 9.1) vulnerability in the JSSE component, Java’s TLS/SSL implementation. Unlike most Java CVEs, this one is not about deserialization, sandbox escapes, or reflection. It is about trust: eight intermediate CA certificates issued by eMudhra (an Indian certificate authority) were shipped inside the JDK’s cacerts trust store, and their private keys were generated with insufficient strength. A man-in-the-middle attacker can exploit this over the network, with no authentication, to impersonate any website to a Java client.

Because the vulnerable trust anchor lives in the JDK itself, every application running on an affected JVM is exposed — web clients, CI/CD dependency downloaders, Liferay DXP connectors, Spring Boot services, Scala build tools, and more. This blog walks through the root cause, an MITM attack flow, affected versions, and a hands-on verification of your local JDK, with remediation steps.

1. Vulnerability at a Glance

2. Root Cause — eMudhra and Weak Intermediate CAs

The JDK ships a default trust store (cacerts) containing root CA certificates that Java trusts by default. Among them were root CAs belonging to eMudhra Technologies Limited. Those roots had signed a set of intermediate CA certificates using private keys that were cryptographically weak.

In a normal TLS handshake, the client validates a server certificate by walking signatures up through intermediate CAs to a trusted root. Because the eMudhra roots are trusted in cacerts, any certificate chain that terminates at them is accepted — including chains built from compromised intermediate CAs. An attacker who obtained (or can abuse) the weak intermediate key can issue a certificate for any hostname (for example *.yourbank.com), chain it to the trusted eMudhra root, and present it to a Java TLS client. The client builds the chain, reaches a trusted root, and accepts the forged certificate.

Fig 2. Trust flow: the eMudhra root is trusted in cacerts; the compromised intermediate signs a forged leaf that the Java client accepts.

3. Attack Flow — Man-in-the-Middle in Practice

The attacker needs only network position between the Java client and its TLS target (public Wi-Fi, compromised router, ISP, or any BGP/ADB-level interception). No credentials, no phishing, no user action:

1. The Java client initiates a TLS handshake to https://target.com.
2. The attacker intercepts the connection and presents a forged leaf certificate for target.com, signed by the weak eMudhra intermediate CA.
3. The JSSE client builds the chain: forged leaf → compromised intermediate → trusted eMudhra root (in cacerts).
4. Chain validation succeeds because the root is trusted. The client completes the TLS handshake with the attacker.
5. The attacker can now read, modify, or relay all traffic — credentials, session tokens, dependency artifacts — while the victim sees a valid green lock equivalent.

Fig 3. MITM attack flow: the victim trusts the eMudhra root; the attacker’s forged chain validates, and traffic is intercepted.

4. Affected Versions

Per the Oracle and OpenJDK advisories, the following supported releases are affected (and earlier builds within each line):

Fig 4. Affected and patched versions for CVE-2026-91403, including local system verification.

5. Local System Verification

We verified the vulnerability conditions on the local workstation used to author this post. The local JDK is Oracle Java SE 21.0.11 LTS, installed at C:\Program Files\Java\jdk-21.0.11. Because 21.0.11 is earlier than the last vulnerable line (21.0.13), it falls under the advisory’s “and earlier” clause and is affected.

# 1) Confirm the local JDK version
java -version
# Expected: java version "21.0.11" 2026-04-21 LTS

# 2) Locate the default trust store
ls "$JAVA_HOME/lib/security/cacerts" 2>/dev/null || ls "$JAVA_HOME/jre/lib/security/cacerts"

# 3) List eMudhra-related entries in cacerts (password: changeit)
keytool -list -v -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit 2>/dev/null | grep -i -A3 emudhra

# 4) Check whether any eMudhra intermediate (weak) CA is trusted
keytool -list -v -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit 2>/dev/null | grep -i emudhra | wc -l

Output confirmed three eMudhra root CAs present in the local cacerts (emSign Root CA - G1, emSign Root CA - G2, emSign ECC Root CA - G3). These are the trust anchors that the compromised intermediates chain to — which is exactly why the local build is vulnerable until patched or the intermediates are distrusted.

6. Remediation & Mitigation

Apply mitigations in this order. The fix is an out-of-band release outside the normal CPU cycle, so do not wait for the next quarterly patch.

Fig 5. Recommended remediation sequence for CVE-2026-91403.

1. Update the JDK immediately. Move to a fixed build newer than the vulnerable releases (past 21.0.13 / 25.0.5 / 27.0.1). Oracle Java SE, GraalVM, and OpenJDK fixes were issued 2026-10-21.
2. Distrust eMudhra intermediates (interim). If you cannot upgrade right away, remove or disable trust for the compromised eMudhra intermediate CAs from cacerts. See ops.java/emudhra.
3. Verify your local trust store. Run the keytool commands in Section 5 and confirm no eMudhra intermediate CA remains trusted.
4. Harden TLS configuration. Enable certificate pinning where practical, restrict outbound TLS destinations, and monitor for unexpected CA issuance. Treat JSSE as part of your network-security perimeter.

7. References

• Oracle — Security Alert Advisory - CVE-2026-91403 (2026-10-21)
• Oracle — Text Form of Security Alert CVE-2026-91403 Risk Matrices
• OpenJDK — OpenJDK Vulnerability Advisory: 2026/10/21
• CVE Record — CVE-2026-91403
• eMudhra remediation reference — ops.java/emudhra
• Red Hat — CVE-2026-91403
• Scala/VirtusLab advisory — Security advisory: update your JDK (CVE-2026-91403)

© 2026 Pyronite Technologies LLP. This post is for defensive and educational purposes. Do not reproduce the attack against systems you do not own or have written authorization to test.