Meta Force Space
BTC $80,418.00 -0.16% ETH $2,329.78 -0.81% SOL $100.94 -0.03% XRP $1.31 -0.95% BNB $748.47 -0.33% DOGE $0.0791 +1.17%
← Back to the news

Ethereum client security fixes leave binary users with a separate Java check

Quick Take

  1. Teku 26.10.3 and Besu 26.10.2 remove four certificate roots from Docker images following the eMudhra incident.
  2. Binary installations depend on separately managed Java, which operators need to check and fix if it remains affected.
  3. Teku reports no exploitation; default mainnet nodes without HTTPS URLs are unaffected by this certificate issue.

Teku and Besu, software used to run Ethereum nodes, have shipped Docker security fixes after a certificate-authority compromise at eMudhra. Operators using affected images can update those containers. Binary installations need a separate check of their Java runtime.

Teku 26.10.3, released Oct. 27, and Besu 26.10.2, released Oct. 26, stop their Docker images trusting four certificate roots: emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2 and AAA Certificate Services.

For Teku, exposure depends on configuration. The team's security notice says default mainnet nodes without HTTPS URLs are unaffected. On an unremediated runtime, an attacker would need to intercept an affected HTTPS connection to impersonate its endpoint. The notice reports no exploitation.

The underlying incident involved recoverable private keys for eight emSign G3 intermediate certificate authorities. eMudhra acknowledged a script error that produced weak keys and said the intermediates were revoked after the Oct. 17 report. Teku's advisory says Java does not check revocation by default, so affected runtimes still need their own remediation.

What operators need to check

The new client images address their bundled trust stores, the lists of certificate authorities Java accepts. Teku's notice identifies all its Docker images through 26.10.2, including the -jdk25 and -jdk26 variants, as retaining the implicated emSign ECC root. Updating Java on the host does not change the runtime inside those containers.

Besu explicitly limits its root-removal change to Docker images: its tar/zip users may still have a JDK that trusts the roots. Teku's binary distribution likewise uses the Java runtime installed by its operator. These installations need that runtime checked and, if it remains affected, fixed separately from the client software.

Deployment decision for Ethereum node operators: use fixed Teku 26.10.3 or Besu 26.10.2 Docker images; separately installed Java needs checking and remediation if affected. Teku exposure requires an affected runtime, outbound HTTPS and traffic interception.

Teku's HTTPS dependencies can include remote signers, beacon nodes, execution clients and builders or relays, as well as proposer configuration, startup data and metrics services. The notice also flags Sepolia, Hoodi and Ephemery, which download starting state over HTTPS when launched with an empty database.

On an unremediated runtime, an attacker who intercepts the connection could impersonate a remote beacon node. That could redirect proposal fees or cause missed validator duties. An attacker impersonating an exposed external signer could obtain signatures for validator exits. The notice says mutual TLS client authentication at the signer limits its impact to denial of service.

Teku's peer-to-peer networking, including libp2p and discv5, does not use certificate authorities and is outside this issue.

Editorial credits

Liam 'Akiba' Wright
Liam 'Akiba' Wright
Editor-in-Chief CryptoSlate

Also known as "Akiba," Liam Wright is a reporter, podcast producer, and Editor-in-Chief at CryptoSlate. He believes that decentralized technology has the potential to make…

Originally published by CryptoSlate on

Read the original on CryptoSlate ↗

Text and images are the property of CryptoSlate and are reproduced here with attribution and a link to the original publication.

More stories

All the latest news