Ethereum clients Teku and Besu patch eMudhra certificate flaw; default nodes unaffected

Ethereum validator client Teku and execution client Besu released new versions on Oct. 27 KST that stop trusting root certificates tied to Indian certificate authority eMudhra, after a security incident at eMudhra affected Ethereum node software. The two teams said a mainnet node running on default settings is not affected, but nodes that connect to outside servers over HTTPS need an update or a check of their Java runtime.

1. April 30, 2025eMudhra creates eight TLS intermediate certificate authorities in a key generation ceremony
2. Oct. 17A researcher notifies Apple, Google, Microsoft and Mozilla at the same time that the private keys can be derived from the public certificates
3. Oct. 18eMudhra revokes all eight intermediate certificate authorities
4. Oct. 20OpenJDK blocks the affected intermediates (CVE-2026-91403)
5. Oct. 23OpenJDK removes four eMudhra and Sectigo roots (CVE-2026-114820)
6. Oct. 27, 2:44 a.m. KSTBesu 26.10.2 ships, removing the roots from its Docker images
7. Oct. 27, 1:57 p.m. KSTTeku 26.10.3 ships with the same change
8. Oct. 28eMudhra says it is winding down its publicly trusted TLS certificate business

Secret keys computed from public certificates

A certificate authority issues the certificates that vouch for a website's identity. According to eMudhra's official statement, an error during the April 2025 key generation process produced a weak set of keys, and certificates built on those keys were added to browser trust lists. The issue went undetected through two audit cycles. On Oct. 17, a researcher reported that the private keys of eight intermediate certificate authorities could be recovered from their public certificates alone.

eMudhra said seven of the eight were never used and the remaining one issued no certificates, adding that its infrastructure was not compromised and no data was breached. Browsers nonetheless distrusted the root certificate above them as a precaution. eMudhra said it is voluntarily winding down its publicly trusted TLS certificate business while its digital signature and other businesses continue.

Java kept trusting the revoked certificates

Browsers, operating systems and the Go language have since blocked the certificates. Java is the problem. According to Teku's notice, Java does not check revocation by default, so anyone holding the keys can create a certificate that Java accepts as genuine. Both Teku and Besu are written in Java, and the Eclipse Temurin runtime inside their Docker images is affected.

Teku said every Docker image up to and including 26.10.2 ships a Java runtime without the fixes. An attacker able to intercept traffic between a node and an outside server could impersonate that server. Teku outlined two worst-case scenarios. By impersonating a remote beacon node, an attacker could have validators propose blocks that pay fees to the attacker. By impersonating an external signer, the attacker could obtain signatures for irreversible voluntary exits or builder registrations that redirect fees. Teku said no exploitation has been reported.

Default nodes unaffected, remote connections are the risk

Teku said a default mainnet node with no https URLs in its configuration needs no action. Only setups that connect to other servers over HTTPS, such as an external signer, a remote beacon node, a builder or relay, a remote execution client or a checkpoint sync URL, are affected. Peer-to-peer networking between nodes does not use certificate authorities and is not affected.

Besu also flagged an inbound risk. If an operator enabled the JSON-RPC TLS option that accepts CA-signed clients (--rpc-http-tls-ca-clients-enabled), an attacker can create a client certificate and connect directly without intercepting any traffic, which Besu classified as the most serious case. The Engine API port uses the same settings.

Ether traded at 3,107,000 won on Upbit as of 3:30 p.m. KST on Oct. 29, down 1.7% from the previous day.