Teku and Besu remove four compromised certificate roots

Teku 26.10.3 and Besu 26.10.2 remove four compromised certificate roots from their Docker images following a security incident at eMudhra, a certificate authority provider. The releases, issued on Oct. 27 and Oct. 26 respectively, require operators using binary installations to perform separate checks on their Java runtimes, as the client updates do not modify host-level trust stores.

Scope of the Docker Fix

The specific update targets the trust stores within the containerized environments of the two Ethereum clients. The removed roots are emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2, and AAA Certificate Services. Teku’s security notice identifies all its Docker images through version 26.10.2, including the -jdk25 and -jdk26 variants, as retaining the implicated emSign ECC root. Updating Java on the host machine does not change the runtime inside these containers, meaning the container-specific fix is necessary to eliminate the compromised trust anchors.

Besu explicitly limits its root-removal change to its Docker images. Users who installed Besu via tar or zip archives may still possess a Java Development Kit (JDK) that trusts the compromised roots. Similarly, Teku’s binary distribution relies on the Java runtime installed by the operator. For these non-containerized setups, the client software update does not address the underlying trust store vulnerability.

Binary Installations and Java Runtime

Operators running binary installations must independently verify their Java environments. If the Java runtime on the host remains affected by the eMudhra incident, it must be fixed separately from the client software. The Teku advisory notes that Java does not check certificate revocation by default. Consequently, even if the compromised intermediate certificates were revoked, an affected Java runtime may still trust them unless the trust store is manually updated or the runtime is patched to enforce revocation checks.

The underlying incident involved recoverable private keys for eight emSign G3 intermediate certificate authorities. eMudhra acknowledged a script error that produced weak keys. The company stated that the intermediates were revoked after an incident report on Oct. 17. However, because standard Java configurations do not perform revocation checks, the presence of the compromised roots in the trust store remains a risk for unremediated systems.

Exposure and Attack Vectors

Teku’s security notice reports no exploitation of the vulnerability to date. The team states that default mainnet nodes configured without HTTPS URLs are unaffected by this certificate issue. Exposure is dependent on specific configurations that rely on HTTPS for communication. Teku’s HTTPS dependencies can include remote signers, beacon nodes, execution clients, builders, relays, proposer configuration, startup data, and metrics services.

The notice also flags the testnets Sepolia, Hoodi, and Ephemery. These networks download starting state over HTTPS when launched with an empty database, creating a potential vector for compromise if the runtime trusts the affected roots. On an unremediated runtime, an attacker who intercepts an affected HTTPS connection could impersonate a remote beacon node. This impersonation could redirect proposal fees or cause missed validator duties. Additionally, an attacker impersonating an exposed external signer could obtain signatures for validator exits. The notice indicates that mutual TLS client authentication at the signer limits the impact of such an attack to denial of service.

Teku’s peer-to-peer networking, which includes libp2p and discv5, does not use certificate authorities and is therefore outside the scope of this issue. The security fix is strictly limited to the HTTPS endpoints and the trust stores that validate them within the client software and its associated Java environments.