Security updates from Teku and Besu address a certificate flaw that attackers could exploit to impersonate validator services and redirect block rewards. Version 26.10.3 of Teku arrived on October 27, one day after Besu shipped version 26.10.2, according to Crypto News.

Weak cryptographic keys from eight certificate authorities run by Indian firm eMudhra created the vulnerability, enabling attackers to generate fraudulent certificates. The updates strip trust for these compromised eMudhra certificates from Docker images that operators use to deploy and run Ethereum node software.

Compromised Certificate Authorities

A cryptographic error involving eight intermediate certificate authorities run by eMudhra started the security issue, with private keys generated using insufficient randomness. On October 17, researchers discovered that data within the public certificates made it possible to mathematically reconstruct the private keys.

Microsoft's October 26 security advisory stated that six of the affected certificates secured internet connections, while the remaining two were associated with code signing. Someone could use the compromised keys to create certificates that appeared genuine to applications still trusting the affected certificate authorities.

On October 18, eMudhra revoked the affected intermediate certificates as technology providers started removing trust for the compromised certificate chains from their software. Microsoft blocked the affected certificate authorities through a Windows security update on October 20, then issued a follow-up patch on October 26 that pulled seven related certificates from its trusted list.

The issue stayed relevant to Ethereum because Teku and Besu rely on Java, which does not check certificate revocation status by default. Affected Java installations could therefore continue accepting certificates from the compromised authorities even after revocation.

Attack Scenarios for Validators

Several possible attack scenarios involving validators communicating with external services through HTTPS connections were identified in Teku's security advisory. In one case, an attacker could pose as a remote beacon node that a validator depends on to coordinate its Ethereum duties.

If an attacker intercepted the connection and presented a forged certificate, the validator might receive falsified data about the block it was getting ready to propose. Teku said this kind of attack could lead a validator to propose a block sending transaction fees to an attacker-controlled address.

External signing services were flagged in the advisory as another component that could be exposed. Such services store validator signing keys apart from the main node software and supply signatures on request. Depending on the configuration and protections in place, an attacker posing as an external signer might be able to obtain signatures tied to validator exits.

This scenario was rated particularly serious by Teku, though setups using mutual TLS authentication could reduce the impact to a denial of service. Execution clients, block builders, relays and services used to retrieve validator configuration information were also listed as potentially affected connections. The vulnerability did not affect Ethereum's underlying peer-to-peer networking protocols, which do not rely on the compromised certificate authorities.

Client Updates and Java Requirements

After the disclosure, Teku shipped version 26.10.3, which strips four certificate roots from its Docker images: emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 and AAA Certificate Services. Besu applied 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. 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.

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.

Teku's developers confirmed that default mainnet configurations were not affected and said there had been no reported exploitation of the vulnerability. Teku warned that attackers could impersonate external services used by Ethereum validators and manipulate block proposals or obtain sensitive validator signatures under certain configurations.

Related Ethereum Security Concerns

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.

Conclusion

Teku and Besu operators must apply the certificate updates and verify their Java environments to protect against potential impersonation attacks. While default mainnet configurations remain unaffected and no exploitation has been reported, validators using external services should review their setups and ensure all components are updated.

The vulnerability did not affect Ethereum's core peer-to-peer protocols, but operators running standalone installations face additional steps to secure their systems. Those using Java 26 must migrate to Java 25 to receive the necessary patches.

Frequently Asked Questions

What is the eMudhra certificate vulnerability affecting Ethereum validators?

The vulnerability involves weak cryptographic keys from eight certificate authorities operated by Indian company eMudhra. Attackers could create fraudulent certificates to impersonate services used by Ethereum validators, potentially redirecting block rewards or obtaining validator signatures under certain configurations.

Which Ethereum clients released patches for the certificate flaw?

Teku released version 26.10.3 on October 27 and Besu released version 26.10.2 on October 26. Both updates remove trust for affected eMudhra certificates from their Docker images, including emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 and AAA Certificate Services.

Do Teku and Besu operators need to update Java separately?

Yes, operators using standalone Teku or Besu installations must update their Java environments separately. The Docker image fixes do not automatically update locally installed Java certificates. Operators still using Java 26 must migrate to Java 25 because Java 26 reached end of life.

Were default mainnet configurations affected by the vulnerability?

No, Teku's developers confirmed that default mainnet configurations were not affected and there had been no reported exploitation. However, validators relying on external services for signing transactions, communicating with beacon nodes or receiving block-building information could be affected under certain configurations.

When did eMudhra revoke the compromised certificates?

eMudhra revoked the affected intermediate certificates on October 18, one day after researchers identified the problem on October 17. Microsoft blocked the certificate authorities through a Windows security update on October 20 and released another update on October 26 to remove seven associated certificates.