eMudhra crisis spreads to Java and Go as OpenJDK issues a critical advisory
OpenJDK has issued a security advisory scored CVSS 9.1 over the compromised keys of India-based certificate authority eMudhra. Because Java does not check certificate revocation by default, forged certificates can be accepted. Go, Rust, Electron and Node.js have also shipped fixes.
The discovery that the private keys of eight intermediate certificates from India-based certificate authority eMudhra could be recovered by anyone has set off fixes across nearly the whole software world, well beyond browsers. After Python, an official warning has come for Java: according to OpenJDK's security advisory dated October 21, the issue is tracked as CVE-2026-91403 and rated critical at 9.1 on the CVSS 3.1 scale. It concerns javax.net.ssl, the component that sets up Java's TLS connections.
Why Java is affected
The compromised intermediates were cross-signed not only by eMudhra's own root but also by Comodo/Sectigo's AAA Certificate Services root. These roots can be present in Java's trusted certificate list (cacerts). While browsers distribute their own blocklists, Java applications do not check certificate revocation by default, and the OpenJDK advisory recommends enabling revocation checking in applications where it is off. As a result, an unpatched Java application may accept a forged certificate issued with these intermediates, letting someone in the middle pose as the server being contacted.
This affects not just web clients but any HTTPS client written in Java: server applications calling other services, API clients and build tools that download dependencies over HTTPS among them.
Affected versions and the fix
The advisory lists 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.32.1, 8u504 and earlier as affected. The reporting researcher's incident page lists 27.0.1.0.2, 25.0.5.0.2, 21.0.13.0.2, 17.0.21.0.2, 11.0.33.0.2 and 8u511 as fixed Oracle JDK versions; Oracle's own release notes could not be reached, so these versions could not be verified separately. Updates from other distributors such as Eclipse Temurin, Amazon Corretto, Microsoft, Azul and Red Hat should be tracked on their own pages.
The fix OpenJDK recommends is adding the compromised certificates to Java's blocklist. According to the advisory, this means updating the lib/security/blocked.certs file in the JDK folder; on JDK 8 the file is named blacklisted.certs. It recommends -Dcom.sun.net.ssl.checkRevocation=true and -Dcom.sun.security.enableCRLDP=true to enable revocation checking for TLS connections, and revocation-checked verification with jarsigner for signed JAR files.
Easier on Linux distributions
According to the advisory, for OpenJDK installed from the operating system's packages on Arch, Debian, Devuan, Fedora, Gentoo, Oracle Linux, RHEL and Ubuntu, updating the operating system's certificates is sufficient. This does not hold on FreeBSD and Homebrew, where Java itself must be updated. The incident page warns that on Debian and Ubuntu Java's certificate store may fall out of sync with the system and recommends reconfiguring the ca-certificates-java package.
Other languages and tools
- Go: Go 1.27.3 and 1.26.10, released October 20 under CVE-2026-111943, filter out chains containing these intermediates during certificate verification. Because Go programs carry the code of the version they were built with, applications must be rebuilt with the new release.
- Rust: webpki-roots 1.0.10, the root list of the rustls ecosystem, removed the emSign ECC Root CA - G3 root.
- Electron: version 44.9.1 includes the mitigation for the compromised eMudhra intermediates; desktop apps must be repackaged with it.
- Node.js: 22.23.4, 24.22.1 and 26.12.1 updated the root list.
- Python: pip 26.2.2, certifi 2026.10.19 and uv 0.13.4 are needed; because pip carries its own list, Python was the hardest-hit ecosystem.
What to do
Identify the Java version and distributor you run on servers and move to your distributor's current release; if you cannot, apply the blocked.certs steps in the OpenJDK advisory. On Linux, update the operating system's ca-certificates package. If you ship applications as container images, refresh the base images and rebuild. Rebuild applications written in Go and Electron with the new releases. You can check whether your application still trusts these certificates by connecting to the test addresses on the incident page.
The details rest on OpenJDK's security advisory, the release notes of Go, Rust and Electron, and the reporting researcher's incident page. The compromised keys were effectively guessable since April 2025, and it is unknown whether they were misused in that time. Server software that does not check Certificate Transparency logs or revocation by default can stay exposed much longer than browsers in incidents like this. Follow assessments from independent security researchers for other perspectives.
