Teku and Besu Patch eMudhra Certificate Risk That Could Redirect Validator Rewards

TL;DR

• Teku 26.10.3 and Besu 26.10.2 remove trust for eMudhra-linked certificate roots after compromised intermediate keys exposed some HTTPS-based validator configurations to impersonation risk.
• Default Teku mainnet nodes were unaffected, and no exploitation has been reported, while risk depended on validators connecting to external services over HTTPS.
• Docker users should update client images, while standalone operators must separately patch Java; Java 26 users need to migrate to supported Java 25 builds.

Teku and Besu released security updates after compromised eMudhra certificate-authority keys left Ethereum node configurations exposed to forged HTTPS connections. Teku’s release notes recommend version 26.10.3, which removes trust for four affected certificate roots from Docker images, while Besu released version 26.10.2. The updates address certificate trust at the software-distribution layer rather than a flaw in Ethereum’s consensus rules. Default Teku mainnet nodes were not affected, keeping the incident distinct from vulnerabilities in the Ethereum protocol.

Compromised Certificate Keys Created an Impersonation Risk

Researchers found that private keys for eight eMudhra intermediate certificate authorities could be recovered because they were generated with insufficient randomness. Although the certificates were revoked, Java does not check revocation by default, leaving runtimes capable of accepting forged certificates. An attacker positioned between a node and an HTTPS service could therefore impersonate that endpoint under vulnerable configurations. The episode reinforces why Ethereum client diversity and operational security extend beyond consensus code.

The highest-risk scenarios involved validators connecting to external services over HTTPS. A forged endpoint could manipulate block-building information, redirect fee recipients, or obtain signatures through an impersonated external signer. Teku said an attacker could cause a validator client using a remote beacon node to propose a block paying fees to the attacker’s address. The risk depended on network position and remote-service configurations, not simply on running Teku or Besu. No exploitation has been reported.

Teku 26.10.3 removes trust for emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 and AAA Certificate Services in Docker images. Besu’s update applies the same approach. Operators running binaries directly must update Java separately because client upgrades do not replace the host runtime’s certificate store. Docker and standalone deployments therefore require different remediation paths. The distinction matters after Ethereum validator infrastructure incidents showed how off-protocol dependencies can affect staking operations.

Java 26 creates a complication because it has reached end of life and will not receive the required patched build, meaning affected operators need to migrate to Java 25. Peer-to-peer Ethereum networking was not exposed because it does not depend on these certificate authorities. The fixes reduce a third-party trust-store risk without repairing a live mainnet exploit or changing Ethereum’s protocol. The episode follows other security work, including the Glamsterdam deposit-routing correction, underscoring how validator safety depends on protocol code and supporting infrastructure.