How do I check whether I am affected by TECH-202610-java-s-blocked-certs-fix-for-the-compromised-emudhra-cas-can?

Check whether your Java runtimes (JDK/JRE, including bundled JREs in apps and containers) still trust the eMudhra roots in their cacerts trust store (keytool -list -cacerts, look for eMudhra entries) and whether your only eMudhra mitigation is the blocked.certs fingerprint entry. If the roots are still trusted, you are exposed to the re-encoded bypass. Affected JDK versions: unknown.

Live › technique › TECH-202610-java-s-blocked-certs-fix-for-the-compromised-emudhra-cas-can

Go to dashboard

high⚡ Early warning · no CVE yetRuntime

Java's blocked.certs fix for the compromised eMudhra CAs can be bypassed by re-encoding the intermediate certificate

Q: What is the fix for TECH-202610-java-s-blocked-certs-fix-for-the-compromised-emudhra-cas-can?

Do not rely on the blocked.certs fingerprint entries alone. Where you can, remove or distrust the relevant eMudhra roots from the Java trust stores you ship (cacerts or a custom truststore). First find the services that legitimately depend on eMudhra chains and test them, then watch for TLS failures after the change. Follow Oracle/OpenJDK vendor guidance as it updates, and check the same thing in other runtimes that ship their own cert stores.

Several eMudhra intermediate CA keys were compromised on 2026-10-20. Java's mitigation adds those intermediates' SHA-256 fingerprints to blocked.certs. Sonatype Research (2026-10-21) showed that an intermediate can be re-encoded without its private key (ECDSA: swap signature s for n-s; RSA: drop the NULL parameter from the outer signature algorithm). The new encoding has a different fingerprint, is not matched by blocked.certs, and still validates in the JDK configurations they tested. So a Java service or client that relies only on blocked.certs may still trust TLS chains through the compromised eMudhra intermediates if an attacker can intercept its traffic. The JDK versions tested are not named. No exploitation reported so far. The same exact-fingerprint weakness may apply to other runtimes or tools that block by fingerprint (unverified).

Summary written from the sources below. Check the originals before acting.

Known so far

4/6

high

no CVSS yet; severity from the sources

known so far4 of 6

missing: primary source, exploitation

First public: Oct 21, 2026 UTC
Last modified: Oct 26, 2026
Status: open
Known exploitation: None reported
Public exploit: None on GitHub
EPSS: not scored

First seen by InfraStack 2026-10-26 23:27 UTC. All times on this page are UTC.

Who is affected

2 products

Product	Ecosystem	Affected	Fixed in
Java	maven	unknown (JDK versions using blocked.certs fingerprint mitigation for eMudhra)	–
OpenJDK	–	unknown	–

Who cares: early-warning, emudhra, java, technique, tls
Not affected if: –

How to check

Check whether your Java runtimes (JDK/JRE, including bundled JREs in apps and containers) still trust the eMudhra roots in their cacerts trust store (keytool -list -cacerts, look for eMudhra entries) and whether your only eMudhra mitigation is the blocked.certs fingerprint entry
If the roots are still trusted, you are exposed to the re-encoded bypass
Affected JDK versions: unknown

The fix

Do not rely on the blocked.certs fingerprint entries alone
Where you can, remove or distrust the relevant eMudhra roots from the Java trust stores you ship (cacerts or a custom truststore)

Know the next one before it finds you.

Add to Slack

Java's blocked.certs fix for the compromised eMudhra CAs can be bypassed by re-encoding the intermediate certificate

Summary written from the sources below. Check the originals before acting.

Product

Ecosystem

Affected

Fixed in

Java

maven

unknown (JDK versions using blocked.certs fingerprint mitigation for eMudhra)

–

OpenJDK

–

unknown

–

Java's blocked.certs fix for the compromised eMudhra CAs can be bypassed by re-encoding the intermediate certificate

Who is affected

How to check

The fix

Know the next one before it finds you.

Java's blocked.certs fix for the compromised eMudhra CAs can be bypassed by re-encoding the intermediate certificate

Who is affected

How to check

The fix

Know the next one before it finds you.

Who had it, and when

Sources