Anyone could recover the private keys for eight certificates. Firefox and Chrome blocked them on 17 October; Oracle and OpenJDK followed four days later.
Oracle gave a Java flaw a score of 9.1 out of 10 on 21 October. The flaw is a list of eight certificates, not a bug in Java code.
The score reflects the risk to trust checks in server side Java. Java trusts what its bundled certificate store says, and that store changes with Oracle's release cycle. Firefox and Chrome blocked the certificates on the day of the report.
A Java server needs a new JDK build, a blocklist file or a flag change. The 9.1 is fair for Java servers, and browsers sit outside Oracle's score.
How the eight keys were recovered
The facts sit on a disclosure page. The private keys of eight intermediate certificates issued by the Indian authority eMudhra were incorrectly generated, so anyone can recover them from the certificates. The certificates chain to roots trusted by the Mozilla, Microsoft, Apple and Chrome programmes.
Six of the eight are for TLS. The other two are for code signing and trusted by Microsoft, according to the Mozilla bug record. The eight keys came from a batch of 24 intermediates created on 30 April 2025.
The keys were so weak that only 256 candidates needed testing. All eight were integers below 256, so each private key was all zeroes apart from its last byte. The report reached Mozilla at 20:06 UTC on 17 October. Mozilla recovered the keys on its own at 21:48 UTC, 1 hour 42 minutes later, by generating the first 256 P-384 keys.
Its block in Firefox was complete at 22:59 UTC, and the disclosure page says Chrome blocked the certificates on the 17th as well.
Why Java needed an update
Java is different. Its TLS library, JSSE (Java Secure Socket Extension), works from the certificate store shipped with the runtime. The OpenJDK advisory says the issue "concerns eight compromised intermediate CA certificates".
OpenJDK offers two workarounds: replacing the blocked.certs file (blacklisted.certs on JDK 8), or enabling revocation checking with two system properties. The disclosure page adds that many clients outside the browser world "do not consume revocation information and require software updates".
Browsers were first and Java was last. Counted from the 17 October report, Firefox and Chrome acted after 0 days, Apple after 2 and Microsoft after 3. Downstream trust stores were told on 19 October. The Oracle alert for Java is dated 21 October, two days after that and four after the report.
Firefox and Chrome blocked the eight compromised eMudhra intermediate certificates on 17 October, Apple on 19 October and Microsoft on 20 October. Oracle and OpenJDK issued Java advisories on 21 October, two days after downstream trust stores were told.
View data
| Trust store | Days after the 17 October report |
|---|---|
| Firefox (OneCRL) | 0 |
| Chrome (CRLSets) | 0 |
| Apple devices | 2 |
| Microsoft platforms | 3 |
| Oracle Java and OpenJDK advisory | 4 |
Trust stores run on different clocks, and the slowest one sets the risk window for machine to machine traffic. A Firefox or Chrome tab was protected within hours. A payment gateway client or a build pipeline running Java keeps trusting the eight certificates. That lasts until someone changes its runtime image or trust store.
Why the full build number matters
The version list requires a check of the full build number. Oracle names Java SE 8u511, 11.0.33, 17.0.21, 21.0.13, 25.0.5 and 27.0.1 as affected. Oracle's release notes date JDK 21.0.13 and 8u511 to 20 October, a day before the alert.
The October Critical Patch Update lists the earlier builds, such as 21.0.12.1 and 17.0.20.1, as the affected ones. A team that applied the quarterly update on Tuesday was exposed again on Wednesday.
The fixed builds keep the release number and add a suffix. Oracle's release notes list a 21.0.13.0.1 build, while the disclosure page lists 21.0.13.0.2 and 17.0.21.0.2 as patched. A scanner that compares only 21.0.13 cannot tell them apart, but the full build string does.
What is known about the risk
One reason to question the score is that browsers that enforce certificate transparency, public logs of every issued certificate, could not be attacked. The intermediates have no log entries from the period, and the disclosure page says that indicates such clients could not have been attacked.
eMudhra's own account is narrower than the headline risk. In the bug record it says the G3B and G3C intermediates were not put into production, with one exception. It also says no end entity certificates were issued from them. The reporter's timeline in the same record says one G3C intermediate was live and has since been disabled.
The Register reports the company putting its TLS business at about one percent of revenue. It also relays eMudhra's account of the cause. In the Register's words, "a flaw in the KGC caused a wrap/unwrap step to produce a second set of weak keys". The weak ones were published to the browser root stores. In the bug record the company says the keys were generated in hardware security modules.
A forged certificate needs no issuance from the CA. Anyone can sign with a recovered key, and the result chains to roots in Java's store. Two things limit harm. The attacker needs a network position, such as a man in the middle, and the client must not enforce certificate transparency.
Outside the browsers, nobody can show the keys went unused since April 2025. The disclosure page says: "We do not know if attackers exploited the flawed key generation to target these clients."
The alert contains one new patch for Oracle Java SE and credits no one. Oracle's risk matrix marks the issue as exploitable remotely without authentication. Confidentiality and integrity impact are high and availability impact is none.
The national vulnerability database published the record at 22:16 UTC on 21 October. It carries only Oracle's score, and at 15:38 UTC on 22 October its status was "Awaiting Analysis".
Options for Java operators
Java services that call external TLS endpoints have three ways to close the gap. Moving to the new JDK build in the next change window is one. Swapping in the blocked.certs file is another, where upgrades must wait. The third is turning on revocation checking, which adds latency and a new failure mode when the revocation server is unreachable.
Services on OpenJDK packages from Arch Linux, Debian, Devuan, Fedora, Gentoo, Oracle Linux, RHEL and Ubuntu use the operating system's certificates. Updating those is enough, according to OpenJDK. FreeBSD and Homebrew packages must be updated directly.
Oracle's next scheduled Critical Security Patch Updates are on 17 November and 15 December 2026. The next full quarterly update is on 19 January 2027. Oracle's advance announcement for the November update is due on Thursday 12 November. Oracle's alerts page lists the schedule.