Skip to main content
Aeterna Sol

Crypto markets, protocols and policy

Ethereum clients patch eMudhra certificate flaw in Docker images

Teku and Besu removed trust in eMudhra certificates from Docker images after weak keys threatened some validator connections; default mainnet nodes remain unaffected.

The Aeterna Sol Editors

Ethereum clients patch eMudhra certificate flaw in Docker images

Eight intermediate certificate authorities linked to Indian firm eMudhra had weak private keys, prompting Ethereum clients Teku and Besu to remove trust in affected certificates from their Docker images. The flaw could let an attacker impersonate an external service a validator connects to, though Teku says default mainnet nodes are unaffected.

Teku released version 26.10.3 on October 27, and Besu released version 26.10.2 a day earlier, according to CoinDesk’s report on the client fixes. Teku’s release notes confirm that its Docker images no longer trust four affected certificate roots.

How could the certificate flaw affect validators?

Researchers found on October 17 that the eight eMudhra intermediate certificates had private keys generated with too little randomness. The keys could be recovered from public certificate data, making it possible to create certificates that appeared to come from trusted authorities. eMudhra revoked the affected certificates the next day, CoinDesk reported.

Java does not check certificate revocation by default. So a Java runtime that still trusted the relevant roots could accept a forged certificate even after a certificate had been revoked.

That matters when a validator’s software connects to outside services over HTTPS. An attacker who could intercept one of those connections might impersonate the service. Teku’s advisory describes a scenario where a fake remote beacon node could feed a validator information that leads it to propose a block sending fees to an attacker’s address. A forged external signer could pose other risks, depending on the setup.

Which Ethereum setups are affected?

Exposure depends on the software and connections an operator uses. Teku says a default mainnet node without HTTPS URLs in its configuration is unaffected and needs no action. Its advisory also reports no known exploitation.

The new Teku and Besu Docker releases remove trust in four roots: emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2, and AAA Certificate Services. Teku’s 26.10.3 release notes say the change applies to its Docker images; they also note that Eclipse Temurin base images do not yet include the same fix.

Operators running either client directly on a machine may need to update the Java runtime and its certificate trust store separately. A client update alone does not necessarily change the certificates trusted by a separately installed Java runtime. Java 26 has reached end of life, so Teku says it will not receive a patched build.

What should operators check now?

If you run Teku or Besu, check how it is installed and which Java runtime it uses. Docker and standalone installations can have different trust stores, so updating one does not automatically update the other.

  1. Update Docker deployments to Teku 26.10.3 or Besu 26.10.2.
  2. For standalone installations, check the Java runtime’s trusted certificates and apply the relevant Java update or certificate changes.
  3. If your setup uses Java 26, move to a supported Java version; Teku identifies Java 25 as the replacement.

The issue sits in the certificate and software layer around Ethereum validators, rather than Ethereum’s peer-to-peer network, CoinDesk reported. The fixes address affected client images, but operators still need to check any separately managed Java runtime.

Sources