Teku 26.10.3 and Besu 26.10.2 remove four certificate roots from their Docker images after the eMudhra certificate-authority incident. Teku's release was published Oct. 27 and Besu's Oct. 26. Operators running binary installations must check their Java runtime separately.
Why it matters
The incident involved recoverable private keys for eight emSign G3 intermediate certificate authorities. eMudhra said a script error produced weak keys and that the intermediates were revoked after an Oct. 17 report. Teku's advisory warns that Java does not check certificate revocation by default, so revocation alone may not protect affected runtimes.
Teku says default Ethereum mainnet nodes without HTTPS URLs are unaffected, and reports no exploitation. Risk depends on configuration: an attacker would need to intercept an affected HTTPS connection to impersonate its endpoint. Teku lists possible HTTPS dependencies including remote signers, beacon nodes, execution clients, builders, relays and validator services. Its peer-to-peer networking is outside the issue because libp2p and discv5 do not use certificate authorities.
Market impact
The fixes remove emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 and AAA Certificate Services from the Docker images. Teku identifies its Docker images through version 26.10.2, including -jdk25 and -jdk26 variants, as retaining an implicated root. Updating Java on the host does not update the runtime bundled inside those containers.
Besu's change applies to Docker images; tar and zip users may still have a JDK that trusts the roots. Teku binary users likewise rely on the Java runtime installed by the operator. If an affected connection is intercepted, an attacker could impersonate a remote beacon node, potentially redirecting proposal fees or causing missed validator duties. Teku also warns that impersonating an exposed external signer could obtain validator exit signatures; mutual TLS client authentication limits the cited impact to denial of service.
Frequently asked questions
-
Which Ethereum client versions remove the affected roots from Docker images?
Teku 26.10.3 and Besu 26.10.2 remove four certificate roots from their Docker images.
-
Why do binary installations need a separate Java check?
Binary installations use a Java runtime managed by the operator, which may still trust the affected roots. Updating Java on the host does not change a runtime bundled inside a container.
-
Are default Ethereum mainnet nodes affected according to Teku?
Teku says default mainnet nodes without HTTPS URLs are unaffected by this certificate issue. It also reports no exploitation.
-
What could happen if an affected HTTPS connection is intercepted?
An attacker could impersonate a remote beacon node, potentially redirecting proposal fees or causing missed validator duties.
-
Does the certificate issue affect Teku peer-to-peer networking?
No. Teku says its libp2p and discv5 peer-to-peer networking does not use certificate authorities and is outside the issue.
CryptoSlate