Docker fixes and separate Java updates
Teku lists version 26.10.3 as a recommended update for the incident. Its Docker update and Besu 26.10.2 remove four roots from their container trust stores: emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2, and AAA Certificate Services.
The distinction between Docker deployments and standalone installations matters. Operators who supply their own Java runtime may need to patch it or modify its trust store separately; replacing the client executable alone may leave the exposure unresolved.
Java's default behavior does not include checking whether certificates have been revoked. An unpatched runtime could therefore continue trusting the revoked eMudhra certificates. OpenJDK released fixes on October 20 and October 23, 2026.
Teku also advised operators using Java 26 to switch to Java 25. Java 26 has reached end of life, and no patched build will be released for it.
CoinDesk reported that Consensys Diligence, Teku's security partner, initially alerted the team to the eMudhra problem.
Which configurations face risks
Certificates help software verify the identity of remote services. Compromised certificate-authority keys can let an attacker impersonate a trusted endpoint where a vulnerable configuration accepts the resulting certificate.
Teku's security notice identifies the external signer as the highest-risk endpoint. Impersonating that service could allow an attacker to obtain signatures for irreversible voluntary exits or builder registrations that redirect fees. If the signer requires Teku to present a client certificate, the notice says the impact is limited to denial of service. It rates an attack through a remote beacon node as medium likelihood.
The notice also identifies potential exposure on the Sepolia, Hoodi, and Ephemery testnets. When started with an empty database, these networks download their starting state over HTTPS. That creates a possible attack path if the runtime still trusts the affected roots.
These warnings do not establish that all operators were exposed or that validator rewards were stolen. Ethereum can keep producing blocks while particular operator environments require security updates; an infrastructure warning is not evidence of an exploited consensus failure.
The certificate incident behind the patches
The incident began on October 17, 2026. According to CoinDesk and eMudhra's statement, an independent security researcher discovered that eight emSign intermediate certificate authorities had private keys generated with too little randomness. The weakness made those keys recoverable from the public certificates. eMudhra revoked all eight intermediates on October 18.
eMudhra traced the weak keys to an April 30, 2025, key-generation ceremony using FIPS 140-2 Level 3 certified hardware security modules. The company said a defect in a key wrap/unwrap operation created a weak second set alongside the original strong keys. The problem remained undetected for about 18 months despite two independent audit cycles.
According to eMudhra, none of the eight affected intermediates had issued publicly trusted end-entity certificates: seven never entered production, and the one deployed had issued no certificates. The company described the impact as limited to TLS certificates chaining to the distrusted ECC root within a single customer ecosystem in the United States.
eMudhra said it will leave the global SSL/TLS certificate business and is offering customers certificates issued by Sectigo instead. Its G1 RSA root certificates remain active and supported during the transition.
What operators need to verify
Operators should check the current Teku and Besu release guidance against their deployment method and Java runtime, then apply the relevant official advisories. Those relying on a node provider should ask how that provider has responded rather than assume its remote services are patched.
The response also calls for reviewing protections around external signers, network connections, and transaction policies. Removing the affected roots addresses one impersonation path, not every operational risk. The next confirmation to look for is whether vulnerable configurations have been updated, rather than an unsupported estimate of network-wide losses.
