What Do Two Patched Ethereum Flaws Mean for Validators and Deposits?
Teku and Besu patched a certificate-trust flaw that could have redirected validator rewards, while a separate Glamsterdam deposit-routing bug was fixed before any funds were lost.
CryptoMEV Bot Newsroom3 min read

Key takeaways
- Teku and Besu patched a vulnerability involving eight compromised certificate authorities.
- No exploitation of the certificate flaw had been reported.
- The separate Glamsterdam deposit-routing fix landed before any funds were lost.
Eight compromised certificate authorities form the root of a patched Ethereum client vulnerability that could redirect validator block rewards, according to Crypto.news. A separate flaw in draft Glamsterdam rules could credit new-validator deposits to builder accounts, but it was fixed before any funds were lost, according to Crypto Briefing.
Certificate failure reaches Ethereum clients
The certificate problem affected intermediate authorities operated by eMudhra. Researchers identified weak cryptographic key generation on October 17 and determined that eight private keys could be mathematically recovered from information in the public certificates.
An October 26 Microsoft advisory said six affected certificates secured internet connections, while two were associated with code signing. eMudhra revoked the affected intermediate certificates on October 18. Microsoft blocked the 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.
Java remained exposed after those revocations because its certificate validation does not check revocation status by default. Teku and Besu therefore released patched Docker images that remove trust for the affected eMudhra certificate chains.
| Key figure | Value |
|---|---|
| Affected certificate authorities | 8 |
| Certificates used for internet connections | 6 |
| Certificates associated with code signing | 2 |
| Teku release and date | 26.10.3, October 27 |
| Besu release and date | 26.10.2, October 26 |
| Initial rejection of the deposit fix | October 19, 2026 |
| Consensus merge window | October 23–28, 2026 |
Rewards could be altered through forged connections
An attacker would first need to intercept an affected HTTPS connection and present a forged certificate accepted by the validator software. Teku’s advisory identified remote beacon nodes, external signing services, execution clients, block builders and relays as potentially affected connections.
If a validator accepted manipulated information from an impersonated beacon node, it could propose a block assigning transaction fees to an attacker-controlled address. An impersonated external signer could potentially obtain signatures associated with validator exits, depending on the configuration and protections in place. Mutual TLS authentication could limit that scenario to a denial of service.
The patches do not amount to a report of an active theft. Teku’s developers said default mainnet configurations were not affected and that no exploitation had been reported. Operators using standalone Teku or Besu installations must update their Java environments separately because the latest Docker image fixes do not update locally installed Java certificates.
For an Ethereum Arbitrage Bot deployment, that distinction between container images and local certificate stores is operationally relevant. Readers following encrypted-mempool latency can use our Decibel coverage separately; the vulnerabilities described here concern certificates and deposit routing.
Glamsterdam deposit sorting was corrected
The second flaw was reported by a researcher using the name avsetsin and affected the draft rules for enshrined proposer-builder separation, or ePBS. Under those rules, staking deposits could be credited to a builder account when builder and validator activity shared the same public key.
The correction routes deposits using withdrawal credentials instead of relying only on public keys. The proposal was initially rejected on October 19, 2026, because it lacked sufficient client support. Maintainer Justin Traglia then merged the change into the consensus specifications between October 23 and October 28, 2026.
The revised logic was exercised on testnets with mixed scheduling results. Sepolia successfully executed the change, while Hoodi postponed its activation after the fix. No funds were lost in the deposit-routing flaw.
Both fixes landed without reported losses
The two incidents required separate responses. The Teku and Besu releases removed trust for compromised certificate chains, while the Glamsterdam correction changed how new-validator deposits are sorted. Neither report described an active exploitation or lost ETH.
For scale, 0 funds were lost.
Sources
- Ethereum clients patch flaw that could redirect ETH rewards — crypto.news, 2026-10-29
- Ethereum clients patch vulnerability to prevent ETH reward redirection — cryptobriefing.com, 2026-10-29



