TLDR
- Ethereum clients Teku and Besu released security updates on October 27 and 26, respectively.
- Weak certificate keys linked to India’s eMudhra could have allowed attackers to impersonate external services.
- Attackers could have redirected Ethereum validator block fees through compromised connections.
- Teku confirmed that default mainnet nodes remain unaffected and reported no known exploitation.
- Developers corrected a Glamsterdam flaw that could have sent validator deposits to builder accounts.
- The revised Glamsterdam rules use withdrawal credentials to distinguish validator deposits from builder deposits.
Ethereum developers fixed two separate flaws that could have threatened validator deposits and block rewards. One involved website certificates. The other affected draft Glamsterdam upgrade rules.
Teku released version 26.10.3 on October 27, following Besu’s 26.10.2 update on October 26. Both releases remove affected certificate authorities from Docker images used by Ethereum nodes.
Ethereum Clients Block Weak Certificates
Researchers discovered on October 17 that eight intermediate certificates issued by India’s eMudhra relied on private keys that attackers could calculate from public information. Attackers could then issue certificates for fake services.
eMudhra revoked the certificates, but some Java installations still trusted them. Java does not check revocation by default. Separately, Google previewed a crypto custody security system this week that divides private keys among separate environments.
How Attackers Could Divert Validator Fees
An attacker who can intercept a validator’s connection to an outside service could impersonate that service. Teku warned that a forged connection to a remote node could cause block fees to reach an attacker-controlled address.
External signing services posed another risk in affected configurations because attackers might obtain signatures that redirect rewards. Teku said, “A default Teku node on mainnet is not affected and needs no action.” It reported no known exploitation.
Glamsterdam Deposit Rules Receive Separate Fix
Developers changed the proposed Glamsterdam rules after researcher avsetsin found a deposit-routing error. Separately, they postponed the Hoodi testnet upgrade scheduled for October 26.
Under the earlier proposal, a builder and a validator sharing one public key could cause staking deposits to enter the builder’s account. Glamsterdam plans to separate block construction from validation.
The revised proposal sorts pending deposits by withdrawal credentials. Developers initially rejected the correction on October 19 because client teams lacked agreement, then added tests and merged the revised rules on October 26.
Node Operators Face Different Next Steps
The Glamsterdam correction has entered Ethereum’s specifications, but software teams still need to implement it. Glamsterdam previously ran on Sepolia, while Hoodi awaits a new activation date.
Operators running Teku or Besu outside Docker must update Java separately. The certificate risk included payments from Ethereum gas fees, such as priority fees paid to validators, rather than ordinary user wallet balances.
Teku advised users of unsupported Java 26 to move to Java 25. The certificate patches address affected Docker images, while the proposed Glamsterdam fix still requires adoption across Ethereum clients.
