Ethereum client developers Teku and Besu have released security updates to address a certificate vulnerability that could allow attackers to impersonate services used by validators and potentially redirect their block rewards.
The issue is linked to weak cryptographic keys associated with eight intermediate certificate authorities operated by Indian digital certificate provider eMudhra. These weaknesses could allow attackers to create fake certificates that appear legitimate and potentially trick affected Ethereum node software into accepting fraudulent HTTPS connections.
Teku released version 26.10.3 on October 27, while Besu released version 26.10.2 on October 26. Both updates remove trust for affected certificates from their Docker images.
Developers said Teku’s default mainnet configuration was not affected and that no exploitation had been reported. However, validators using certain external services could face risks if attackers managed to intercept their connections and present forged certificates.
The problem was traced to eight intermediate certificate authorities whose private keys were generated with insufficient randomness. Researchers identified the weakness on October 17 and found that the keys could be recovered using information available in public certificates.
According to a Microsoft security advisory published on October 26, six of the affected certificates were used to secure internet connections, while the other two were associated with code signing.
The compromised keys could allow attackers to create fraudulent certificates that applications might accept as genuine. eMudhra revoked the affected certificates on October 18, and technology providers began removing trust in the compromised certificate chains.
Microsoft blocked the affected certificate authorities through a Windows security update on October 20 and issued another update on October 26 to remove seven associated certificates from its trusted list.
However, Ethereum node operators faced an additional concern because Java does not check certificate revocation status by default. As a result, some Java installations could continue accepting certificates linked to the compromised authorities even after they had been revoked.
Teku’s security advisory described several possible ways attackers could exploit the weakness. One involves impersonating a remote beacon node that a validator uses to coordinate its duties on Ethereum. If an attacker successfully intercepted the connection, they could send manipulated information about a block being prepared for proposal.
In certain circumstances, this could cause a validator to propose a block that directs transaction fees to an address controlled by the attacker.
Another possible target is an external signing service, which stores validator signing keys separately from the main node software and provides signatures when requested. An attacker impersonating such a service could potentially obtain signatures related to validator exits, depending on the system’s configuration and security protections.
Teku also identified connections involving execution clients, block builders, relays and services that provide validator configuration information as potentially exposed. Configurations using mutual TLS authentication could limit some attacks, although service disruption might still be possible.
The vulnerability does not affect Ethereum’s underlying peer-to-peer networking protocols, which do not rely on the compromised certificate authorities.
To address the issue, Teku version 26.10.3 and Besu version 26.10.2 remove four affected certificate roots from their Docker images: emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 and AAA Certificate Services.
Operators using standalone Teku or Besu installations must take additional steps because the updates do not automatically change certificates in separately installed Java environments. They should check their Java runtime and update its trusted certificates where necessary.
Teku also warned operators using Java 26 to migrate to Java 25 because Java 26 had reached end of life and would not receive the required patched build.
Certain testnet configurations could also be exposed, including setups that download their initial blockchain state over HTTPS.
These updates come amid other recent security and development concerns across Ethereum’s ecosystem. Earlier this month, MetaMask reportedly began exiting affected validators following a separate infrastructure security incident disclosed on September 30.
Ethereum developers have also addressed a validator deposit flaw in the upcoming Glamsterdam upgrade after researchers identified a scenario in which builder accounts could receive ETH intended for validators.
Separately, developers postponed the planned activation of the Glamsterdam-related changes on the Hoodi testnet to investigate smart contract compatibility concerns involving EIP-8037. The postponement affected the planned Amsterdam execution and Gloas consensus changes, along with a proposed increase in Hoodi’s gas limit to 200 million. A replacement activation date has not been announced.