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.
Summary
- Ethereum clients Teku and Besu have released security updates after a certificate vulnerability was found that could allow attackers to redirect validator block rewards to their own addresses.
- The vulnerability originated from weak cryptographic keys associated with eight certificate authorities operated by Indian company eMudhra, which could allow attackers to create fraudulent certificates.
- Teku warned that attackers could impersonate external services used by Ethereum validators and manipulate block proposals or obtain sensitive validator signatures under certain configurations.
- Default Teku mainnet configurations were not affected, and developers confirmed that no exploitation of the vulnerability had been reported.
- Operators using standalone Teku or Besu installations must update their Java environments separately, as the latest Docker image fixes do not automatically update locally installed Java certificates.
According to security advisories accompanying the releases, the issue originated from compromised certificate authority keys belonging to Indian digital certificate provider eMudhra, which left certain Ethereum node configurations exposed to forged HTTPS connections.
Teku released version 26.10.3 on October 27, while Besu introduced version 26.10.2 a day earlier. Both updates remove trust for affected eMudhra certificates from their Docker images, which operators use to deploy and run Ethereum node software.
The vulnerability could affect validators that rely on external services for signing transactions, communicating with beacon nodes or receiving block-building information. An attacker would need to intercept an affected connection and present a forged certificate that the validator’s software accepts as legitimate.
Teku’s developers confirmed that default mainnet configurations were not affected and said there had been no reported exploitation of the vulnerability.
Ethereum security flaw traced to compromised eMudhra certificates
The security issue began with a cryptographic error involving eight intermediate certificate authorities operated by eMudhra, whose private keys were found to have been generated using insufficient randomness.
Researchers identified the problem on October 17, discovering that the private keys could be mathematically recovered from information available in the public certificates.
According to an October 26 security advisory from Microsoft, six of the affected certificates were used for securing internet connections, while the remaining two were associated with code signing.
The compromised keys could allow someone to create certificates that appeared genuine to applications that continued trusting the affected certificate authorities.
eMudhra revoked the affected intermediate certificates on October 18, while technology providers began removing trust for the compromised certificate chains from their software.
Microsoft subsequently blocked the affected certificate authorities through a Windows security update on October 20 and released another update on October 26 to remove seven associated certificates from its trusted list.
However, the problem remained relevant to Ethereum because Teku and Besu use Java, whose certificate validation does not check revocation status by default.
As a result, affected Java installations could continue accepting certificates associated with the compromised authorities even after their revocation.
How attackers could redirect Ethereum validator rewards
Teku’s security advisory identified several possible attack scenarios involving validators that communicate with external services through HTTPS connections.
One scenario involves an attacker impersonating a remote beacon node used by a validator to coordinate its duties on Ethereum.
If the attacker successfully intercepted the connection and presented a forged certificate, the validator could receive manipulated information about the block it was preparing to propose.
According to Teku, such an attack could cause a validator to propose a block that directs transaction fees to an address controlled by the attacker.
The advisory identified external signing services as another potentially exposed component. These services hold validator signing keys separately from the main node software and provide signatures when requested.
An attacker impersonating an external signer could potentially obtain signatures associated with validator exits, depending on the configuration and available protections.
Teku classified this scenario as particularly serious, although configurations using mutual TLS authentication could limit the consequences to a denial of service.
Other potentially affected connections include execution clients, block builders, relays and services used to retrieve validator configuration information.
The vulnerability did not affect Ethereum’s underlying peer-to-peer networking protocols, which do not rely on the compromised certificate authorities.
Teku and Besu release fixes for affected Ethereum nodes
Following the disclosure, Teku released version 26.10.3 to remove four certificate roots from its Docker images, including emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 and AAA Certificate Services.
Besu introduced the same certificate removals in version 26.10.2, addressing the risk for operators using its updated Docker images.
However, the releases do not automatically update Java installations maintained separately by node operators.
Users running Teku or Besu through standalone binary distributions must check their installed Java runtime and update its trusted certificates where necessary.
Teku warned that operators still using Java 26 would need to migrate to Java 25 because the former version had reached end of life and would not receive the required patched build.
The advisory further identified certain testnet configurations as potentially exposed, including setups that download their initial blockchain state over HTTPS.
The security updates follow other recent concerns involving Ethereum validator infrastructure. Earlier this month, crypto.news reported that MetaMask had begun exiting affected validators following a separate infrastructure security incident disclosed on September 30.
More recently, Ethereum developers corrected a validator deposit flaw in the upcoming Glamsterdam upgrade after researchers identified a scenario where builder accounts could receive ETH intended for validators.
The Glamsterdam upgrade has separately faced delays after developers postponed its Hoodi testnet activation to investigate smart contract compatibility concerns involving EIP-8037.
The October 26 postponement removed the scheduled activation of both the Amsterdam execution changes and Gloas consensus changes, along with a proposed increase in Hoodi’s gas limit to 200 million. Ethereum developers have not announced a replacement activation date.
