Oracle’s Emergency Java Fix Cuts eMudhra’s Weak Certificates Loose
Oracle's out-of-band CVE-2026-91403 fix (CVSS 9.1) stops Java trusting eight eMudhra intermediate certificates with weak keys; a second update, CVE-2026-114820, removes the related roots.
The eMudhra certificate mess has reached Java. Oracle put out an out-of-band security alert on Oct. 21 for CVE-2026-91403, a CVSS 9.1 flaw in how Java decides which HTTPS certificates to trust, Cyber Security News reports. The problem is eight intermediate certificates from Indian certificate authority eMudhra that were issued with weak private keys. Anyone holding those keys could mint a certificate for any website, and Java would have accepted it. Oracle’s update stops trusting them.
For defenders
The bug: CVE-2026-91403 in the JSSE component, CVSS 3.1 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N). That’s high confidentiality and integrity impact, no availability impact, no login or user action needed. Oracle lists Java SE 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5 and 27.0.1, GraalVM for JDK 17.0.21 and 21.0.13, and GraalVM Enterprise 21.3.20 as affected; older unsupported releases weren’t tested. The OpenJDK project published a matching advisory the same day.
Who can exploit it: an attacker who can sit between a Java client and the server it’s talking to, such as on a hostile network or through hijacked DNS, and present a forged certificate. Oracle reports no attacks so far. EPSS is about 0.3%, it isn’t in CISA’s KEV catalog, and the CVE data counts four GitHub repositories claiming proof-of-concept code.
Follow-up: on Oct. 24 Oracle issued CVE-2026-114820 (also CVSS 9.1) for the same trust problem. That update removes three emSign root certificates and the Comodo AAA root from Java’s cacerts. Fix both.
If you can’t update yet: Oracle’s eMudhra guidance says to replace the local blocked.certs file with Oracle’s version (blacklisted.certs on Java 8), keeping any custom entries. The alternative is turning on revocation checking with -Dcom.sun.net.ssl.checkRevocation=true and -Dcom.sun.security.enableCRLDP=true. Test either change before rolling it out. Browsers and Go already blocked the same certificates last week.
What it means for you
Java runs behind a huge amount of business software, from internal company apps to the servers behind websites. When it connects to another site, it checks a digital certificate to make sure it’s talking to the real thing. This bug meant a criminal could have faked that certificate. For most people there’s nothing to do: your apps and vendors need to update. If you run a small business with software that bundles its own Java, ask the vendor when they’re shipping the fix.
Do this now
- Update every Java runtime to the October 24 builds that fix both CVE-2026-91403 and CVE-2026-114820. Check your distributor’s notice for Temurin, Red Hat or other builds.
- Don’t forget Java bundled inside apps and container images. Rebuild images that ship their own JDK.
- Can’t update this week? Apply Oracle’s blocked-certificate file or enable revocation checking, and test it first.
- Never “fix” certificate errors by turning off certificate or hostname validation.
CVE at a glance
- CVSS
- 9.1 Critical (v3.1)
- EPSS
- 0.3% chance of exploitation in the next 30 days (higher than 24% of CVEs)
- Exploited in the wild
- Not on CISA’s KEV list
- Public exploit
- Yes, reported in 4 GitHub repositories
- CVSS
- 9.1 Critical (v3.1)
- EPSS
- 0.3% chance of exploitation in the next 30 days (higher than 16.6% of CVEs)
- Exploited in the wild
- Not on CISA’s KEV list
- Public exploit
- Yes, reported in 1 GitHub repository
Data from NVD, FIRST EPSS and CISA KEV, refreshed automatically. We report whether public exploit code exists but never link to it: fake proof-of-concepts that infect researchers are common.