Ethereum developers have resolved two separate vulnerabilities that could have put validator deposits and block rewards at risk: one involving weak website certificates and the other embedded in draft rules for the network's forthcoming Glamsterdam upgrade. Teku, a consensus client, and Besu, an execution client, each shipped patches to address the exposure. Ethereum nodes run a consensus client and an execution client alongside each other, meaning both layers of the node stack required the same certificate cleanup.

Teku released version 26.10.3 on October 27, one day after Besu shipped version 26.10.2 on October 26. Both releases remove the affected certificate authorities from the Docker images used to run Ethereum nodes, according to Teku's release page.

Weak Certificate Keys Flagged

Researchers discovered on October 17 that eight intermediate certificates issued by India's eMudhra relied on private keys that attackers could calculate from publicly available information. With those keys, attackers could have issued certificates for counterfeit services. eMudhra revoked the certificates, but some Java installations continued to trust them, because Java does not check certificate revocation by default. Both Teku and Besu are written in Java, which is how the weakness reached Ethereum node operations.

The discovery came in the same week that Google previewed a crypto custody security system designed to divide private keys among separate environments.

How Validator Fees Could Have Been Diverted

The certificate flaw mattered because validators depend on connections to outside services. An attacker able to intercept such a connection could impersonate the service on the other end. Teku warned that a forged connection to a remote node could cause block fees to be paid to an attacker-controlled address. External signing services posed an additional risk in affected configurations, since attackers might obtain signatures that redirect rewards.

"A default Teku node on mainnet is not affected and needs no action," Teku said. The client team reported no known exploitation.

Glamsterdam Deposit Rules Corrected

In a separate effort, developers revised the proposed Glamsterdam rules after researcher avsetsin identified a deposit-routing error. They also postponed the Hoodi testnet upgrade, which had been scheduled for October 26.

Under the earlier draft, a builder and a validator sharing a single public key could have caused staking deposits to enter the builder's account. Glamsterdam is designed to separate block construction from validation, and the revised proposal sorts pending deposits by withdrawal credentials, distinguishing validator deposits from builder deposits.

Client teams initially rejected the correction on October 19 because they lacked agreement. Developers subsequently added tests and merged the revised rules on October 26.

Different Next Steps for Node Operators

The Glamsterdam correction has entered Ethereum's specifications, but software teams still need to implement it. Glamsterdam previously ran on the Sepolia testnet, while Hoodi awaits a new activation date.

Operators running Teku or Besu outside Docker must update Java separately. The certificate risk covered payments drawn from Ethereum gas fees, such as priority fees paid to validators, rather than ordinary user wallet balances. Teku advised users of the unsupported Java 26 to move to Java 25.

The certificate patches resolve the affected Docker images, while the Glamsterdam fix awaits adoption across Ethereum's client ecosystem.