CVE-2026-91403: Cryptographic Trust Validation Bypass in Oracle Java SE JSSE via Compromised eMudhra Intermediate CAs

CVE-2026-91403 (also tracked as GHSA-9h75-rf66-wh3r) affects the Java Secure Socket Extension (JSSE) within Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition, and downstream OpenJDK distributions. JSSE provides the core framework and implementation for Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols in Java applications. It is responsible for authenticating remote peers during TLS handshakes by validating X.509 certificate chains against the local runtime trust store ($JAVA_HOME/lib/security/cacerts).

The vulnerability stems from an external cryptographic incident in October 2026, where the private signing keys for eight intermediate Certificate Authorities (CAs) operated by eMudhra (emSign) were compromised. These eight intermediates encompass six TLS-issuing CAs (covering Domain Validated, Organization Validated, and Extended Validation certificates) and two Organization Validated Code-Signing CAs. Because each intermediate certificate was issued under native emSign root CAs and simultaneously cross-signed by Sectigo's AAA Certificate Services root, 16 distinct intermediate certificate paths became untrustworthy across global public key infrastructure.

In unpatched Java runtime environments, the root certificates anchoring these 16 intermediates (emSign ECC Root CA - G3 and AAA Certificate Services) are present and trusted by default in the cacerts keystore. Furthermore, JSSE does not perform online certificate revocation checks via OCSP or CRL by default. Consequently, any Java client or server relying on the default TrustManager implementation will accept fraudulent leaf certificates signed by the compromised eMudhra private keys.

Classified under CWE-327 (Use of a Broken or Risky Cryptographic Algorithm / Broken Trust Anchor Validation) with a CVSS v3.1 base score of 9.1, this flaw exposes all outbound and mutually authenticated inbound TLS connections in affected JVMs to unauthenticated Adversary-in-the-Middle (AiTM) attacks. An attacker with network-level interception capabilities can impersonate arbitrary hosts, decrypt sensitive application payloads, capture authentication credentials, and inject modified responses into the encrypted communication stream.

The technical root cause of CVE-2026-91403 is the intersection of an upstream CA private key compromise and the architectural design of certificate path validation within OpenJDK's sun.security.validator.PKIXValidator and sun.security.provider.certpath packages. When a Java application initiates a TLS connection via standard APIs such as javax.net.ssl.HttpsURLConnection, SSLContext, SSLSocket, or third-party wrappers like Apache HttpClient and OkHttp, JSSE delegates peer certificate verification to the configured X509TrustManager.

During the checkServerTrusted execution path, the validator constructs a certification path from the peer's leaf X.509 certificate through any provided intermediate CA certificates up to a trusted root anchor stored in $JAVA_HOME/lib/security/cacerts. Cryptographic verification succeeds if the digital signatures along the chain are mathematically valid, the certificates are within their validity periods, and the BasicConstraints and KeyUsage extensions permit certificate signing. Because the threat actor possesses the legitimate private keys for the eMudhra intermediate CAs, forged leaf certificates carry mathematically valid cryptographic signatures that chain cleanly to trusted roots.

To prevent the use of compromised certificates before their natural expiration date, PKI relies on online revocation protocols (OCSP and CRLs) or static runtime blocklists. However, OpenJDK disables online revocation checking by default (com.sun.net.ssl.checkRevocation is false and com.sun.security.enableCRLDP is false) to avoid connection latency and hard-fail availability issues when CA revocation servers are unreachable. Therefore, even after eMudhra and Sectigo revoked the compromised intermediate certificates via CRL and OCSP, standard Java runtimes never query those revocation endpoints during TLS handshakes.

Instead of dynamic revocation, Java relies on a static blocklist mechanism implemented in sun.security.util.UntrustedCertificates, which reads SHA-256 certificate fingerprints from $JAVA_HOME/lib/security/blocked.certs (or $JAVA_HOME/jre/lib/security/blacklisted.certs in Java 8). Prior to the October 2026 security updates, the blocked.certs file in Java SE 8, 11, 17, 21, 25, and 27 did not contain the 16 SHA-256 fingerprints of the compromised eMudhra and Sectigo cross-signed intermediates, leaving the trust validation logic unable to reject chains built through these compromised keys.

Unlike memory corruption or logic bugs in application code, CVE-2026-91403 resides in the cryptographic configuration data and trust enforcement tables shipped with the JDK. When PKIXValidator evaluates a certificate chain, it invokes AlgorithmChecker and UntrustedCertificates.isUntrusted(X509Certificate cert) on every certificate in the chain. The UntrustedCertificates class loads the static properties file $JAVA_HOME/lib/security/blocked.certs at class initialization and computes the SHA-256 hash over the DER-encoded bytes of each presented X.509 certificate.

To verify whether a deployed Java runtime exposes the vulnerable trust anchors, Oracle provided the diagnostic reference implementation CheckCerts.java (https://cr.openjdk.org/~mr/CheckCerts.java). This utility initializes the default TrustManagerFactory, iterates through all accepted X509Certificate issuers in the default keystore, and checks for the presence of the affected root CAs (emSign ECC Root CA - G3 and AAA Certificate Services).

import javax.net.ssl.*;
import java.security.*;
import java.security.cert.*;
import static java.lang.System.out;
 
public class CheckCerts {
    // Root CAs that anchor the 16 compromised eMudhra intermediate certificates
    private static final String[] ROOTS = {
        "emSign ECC Root CA - G3",
        "AAA Certificate Services"
    };
 
    public static void main(String... args) throws Exception {
        out.format("Java runtime version %s at %s%n",
                   System.getProperty("java.runtime.version"),
                   System.getProperty("java.home"));
 
        // Load the default JSSE TrustManagerFactory using the system cacerts keystore
        TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
        tmf.init((KeyStore) null);
        boolean badroots = false;
 
        for (String r : ROOTS) {
            for (TrustManager tm : tmf.getTrustManagers()) {
                if (tm instanceof X509TrustManager) {
                    // Inspect all trusted root anchors configured in the JVM
                    for (X509Certificate cert : ((X509TrustManager) tm).getAcceptedIssuers()) {
                        String nm = cert.getSubjectX500Principal().getName();
                        if (nm.contains("CN=" + r)) {
                            out.format("BAD ROOT: %s%n", nm);
                            badroots = true;
                        }
                    }
                }
            }
        }
 
        if (badroots) System.exit(1);
        else out.format("No bad root certificates found%n");
    }
}

The official patch in OpenJDK and Oracle Java SE updates the $JAVA_HOME/lib/security/blocked.certs file by appending the 16 SHA-256 fingerprints corresponding to the DER encoding of each compromised intermediate certificate. Below is the exact configuration diff applied to blocked.certs:

 Algorithm=SHA-256
+# Compromised eMudhra / emSign and Sectigo AAA cross-signed Intermediate CAs (CVE-2026-91403)
+42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
+45A883F349AEDFD5F3A649B5498FFB121712BA8B448F3F2A91DBC5A766FCDDBE
+98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
+5F1DED4DD590AF74631290CF073B122A2AAC6A1FA479778A0BD43579BD832699
+E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
+579480AEA166290BD3C643589E795FC0D0E54E86505D180F1DFF99EFD3199512
+0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
+62B7F9868263F72F6911FC78CEAF72C1979158B7368BF648683BB2AA39B02E72
+CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
+7485B51C0ED192878FA1D2F948FB529AE1842CC5086C4B67F7BE5B2039DE9489
+432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
+FD9D5C2DBBD4995AB69B8D50C439D9527B00529199C2FD01B2174EB58F07021F
+9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
+A496E23AC0CAB8155FC9B117B97EAE368EFCBB9041AEC8804D5A308D2D01C2D8
+4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1
+84112972B8E59D14560AE7E7119654474AAD119990CF3722BFC1E3B91615E1FD

Regarding fix completeness: blocking all 16 intermediate certificate fingerprints completely neutralizes any leaf certificate signed by the 8 compromised private keys, regardless of whether the attacker presents the native emSign chain or the cross-signed Sectigo AAA chain. Because X.509 intermediate certificates include the public key and issuer signature over the TBSCertificate structure, an attacker possessing only the intermediate private key cannot alter the intermediate certificate's DER representation (and thus its SHA-256 fingerprint) without invalidating the root CA's signature over the intermediate. However, applications that override the default SSLContext with custom X509TrustManager implementations that bypass PKIXValidator remain vulnerable if they do not consult UntrustedCertificates.

Exploiting CVE-2026-91403 requires two primary prerequisites: possession of at least one of the compromised eMudhra intermediate CA private keys, and an in-path network position (Adversary-in-the-Middle) between the target Java application and the remote TLS endpoint it communicates with. No authentication, user interaction, or prior access to the target host is required. Because Java backend services, microservices, and CLI utilities initiate outbound HTTPS connections autonomously, exploitation is completely transparent to system operators.

To execute the attack, the adversary generates a new RSA or ECDSA key pair and creates a Certificate Signing Request (CSR) containing a Subject Alternative Name (SAN) matching the target domain (e.g., api.payment-gateway.com or an internal service FQDN). Using the compromised private key of an intermediate such as EM DV TLS CA - G3B, the attacker signs the CSR to produce a fraudulent leaf certificate. The attacker then configures a TLS interception proxy (such as mitmproxy or a custom OpenSSL listener) with the forged leaf certificate and the corresponding EM DV TLS CA - G3B intermediate certificate (chained either to emSign ECC Root CA - G3 or AAA Certificate Services).

Next, the attacker redirects traffic from the victim JVM to the interception proxy using ARP spoofing on a local subnet, DNS cache poisoning, rogue BGP route announcements, or compromised transit infrastructure. When the victim JVM initiates a ClientHello, the attacker's proxy responds with a ServerHello and presents the forged certificate chain. The unpatched JVM validates the leaf signature using the intermediate's public key, and validates the intermediate's signature against the AAA Certificate Services or emSign ECC Root CA - G3 entry in cacerts. The handshake completes, allowing the attacker to read cleartext HTTP headers, OAuth bearer tokens, API keys, and payload data, or inject arbitrary responses.

In addition to TLS interception, two of the compromised intermediates (EM OV CS CA - G3B and EM OV CS CA - G3C) have the codeSigning Extended Key Usage (EKU) OID (1.3.6.1.5.5.7.3.3). An attacker can use these keys with jarsigner to sign malicious JAR archives. Security controls or deployment pipelines relying on jarsigner -verify on unpatched JVMs will validate the malicious archive as authentically signed by a trusted authority.

> [!NOTE] > Community researchers have established live diagnostic test domains (such as https://dv-g3b-emudhra.we-have-a-problem.com/ and https://dv-g3b-aaa-emudhra.we-have-a-problem.com/) and published open-source verification scanners (EmudhraCheck.java, CVE-2026-91403-eMudhra-Java-Scanner) that test whether a JVM completes a TLS handshake against chains anchored to the compromised intermediates.

The CVSS v3.1 score of 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) reflects high impact to both Confidentiality (C:H) and Integrity (I:H) with low attack complexity (AC:L) and no privileges or user interaction required (PR:N/UI:N). Availability is rated None (A:N) because the flaw does not inherently crash the JVM, though an active AiTM attacker can selectively drop traffic. The vulnerability affects all standard enterprise Java deployments, including Spring Boot microservices, Apache Kafka brokers using TLS, Elasticsearch nodes, Jenkins controllers, and Android/desktop clients built on affected JDKs.

Particularly severe is the inclusion of the Sectigo AAA Certificate Services cross-signed path. While some organizations strip regional root CAs like emSign from custom trust stores, AAA Certificate Services is a legacy root universally present in almost all operating system and Java trust stores to maintain backward compatibility across the web. Consequently, even hardened keystores that retained AAA Certificate Services are vulnerable to the eight cross-signed eMudhra intermediates.

Security teams inspecting network traffic, TLS logs, or local certificate stores should monitor for the following 16 SHA-256 fingerprints (calculated over the DER-encoded intermediate certificates):

Additionally, the four associated root certificates tracked in Oracle's advisory scope are emSign ECC Root CA - G3 (86a1ecba089c4a8d3bbe2734c612ba341d813e043cf9e8a862cd5c57a36bbe6b), AAA Certificate Services (d7a7a0fb5d7e2731d771e9484ebcdef71d5f0c3e0a2948782bc83ee0ea699ef4), emSign Root CA - G1 (40f6af0346a99aa1cd1d555a4e9cce62c7f9634603ee406615833dc8c8d00367), and emSign Root CA - G2 (1aa0c2709e831bd6e3b5129a00ba41f7eeef020872f1e6504bf0f6c3f24f3af3).

The primary and recommended remediation is to upgrade all affected Oracle Java SE, GraalVM, and OpenJDK installations to the out-of-band patched releases issued in late October 2026. Specifically, organizations should upgrade to Oracle Java SE 8u511 (patched build), 11.0.33.0.2+, 17.0.21.0.2+, 21.0.13.0.2+, 25.0.5.0.2+, or 27.0.1+, or the corresponding OpenJDK / Eclipse Temurin point releases (such as 25.0.5+8, 21.0.13+x, and 17.0.21+x). These updates populate blocked.certs with the 16 compromised intermediate fingerprints while preserving valid certificates issued under AAA Certificate Services by non-compromised intermediates.

If an immediate JDK binary upgrade is not operationally feasible, administrators can apply an in-place configuration workaround by manually appending the 16 SHA-256 fingerprints to the JVM's certificate blocklist file. On Java 11 and later, edit $JAVA_HOME/lib/security/blocked.certs; on Java 8, edit $JAVA_HOME/jre/lib/security/blacklisted.certs. Ensure the file begins with Algorithm=SHA-256 and append the 16 hex strings (one per line), then restart all running Java processes so UntrustedCertificates reloads the list.

In legacy environments where the blocked.certs mechanism is unavailable or custom keystores are used, administrators can remove the four root CA certificates directly from $JAVA_HOME/lib/security/cacerts using keytool:

# Back up the existing trust store before modification
cp "$JAVA_HOME/lib/security/cacerts" "$JAVA_HOME/lib/security/cacerts.bak"
 
# Remove the emSign and Sectigo AAA root aliases
keytool -delete -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit -alias "emsigneccrootcag3"
keytool -delete -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit -alias "comodoaaaca"
keytool -delete -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit -alias "emsignrootcag1"
keytool -delete -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit -alias "emsignrootcag2"

> [!WARNING] > Deleting the comodoaaaca (AAA Certificate Services) root alias from cacerts will break TLS connections to legitimate external servers that still rely on Sectigo cross-signing for root trust. Prefer the blocked.certs fingerprint approach whenever possible to avoid collateral service disruptions.

For Linux distributions and container images where $JAVA_HOME/lib/security/cacerts is symlinked to the host operating system's shared certificate bundle (/etc/ssl/certs/java/cacerts), updating the JDK package alone may not overwrite the trust store if it is managed by ca-certificates-java. In Debian/Ubuntu-based containers, update the OS certificate bundle and regenerate the Java keystore:

sudo apt update && sudo apt install --only-upgrade ca-certificates 'libnss3*'
sudo rm -f /etc/ssl/certs/java/cacerts
sudo update-ca-certificates --fresh