Teku and Besu remove eMudhra roots after validator fee-risk warning

Teku released version 26.10.3 on October 27, 2026, and Besu released version 26.10.2 on October 26, both removing compromised-certificate trust roots from their Docker images. The fixes address a route through which an attacker intercepting a validator’s outbound HTTPS connections could redirect fees or disrupt validator duties.

The security advisory for Teku states that a default node on mainnet is not affected and needs no action, defining a default configuration as having no HTTPS URLs. The advisory also confirms that no exploitation has been reported, noting that the described attacks are possible outcomes rather than accounts of stolen rewards.

Root cause of the risk

The vulnerability stems from eight eMudhra intermediate certificate authorities whose private keys were shown to be recoverable from public certificates on October 17 and subsequently revoked on October 18. Java runtimes do not check certificate revocation by default, meaning they continued to trust the revoked certificates even after browsers and other systems blocked them.

An attacker with a compromised key can impersonate an HTTPS service trusted by an unpatched runtime, but they must still intercept traffic between the validator client and that service. The exposure is limited to outbound connections, as Teku does not accept client certificates on its APIs, and peer-to-peer networking uses no certificate authorities and is unaffected.

How an attacker could exploit the flaw

The advisory identifies the external signer as the highest-risk endpoint. By impersonating it, an attacker could obtain signatures for irreversible voluntary exits and builder registrations that redirect fees, or capture credentials embedded in the signer URL. They could also create slashable signatures if the signer’s own slashing protection is disabled.

An impersonated remote beacon node could supply blocks paying fees to an attacker, as the validator client does not check the payload before signing. The node could also cause missed or incorrect attestations, though Teku’s own slashing protection still blocks slashable signatures in this scenario. The advisory rates the exposure for an internet-connected remote beacon node above that of the execution-client connection, which is usually local.

Proposer configuration fetched from a URL gives another way to change fee recipients. An attacker could substitute fee recipients and builder settings for every validator using that configuration, and with refresh enabled, the substitution could repeat every epoch. The advisory describes remotely loaded proposer configuration as uncommon, so a successful substitution would affect only the validators covered by that configuration.

A directly connected builder or relay could deliver a block paying the attacker, censor transactions, or withhold the payload after signing and cause a missed proposal. A local mev-boost checks relay keys itself. An impersonated remote execution client could report invalid payloads as valid and supply proposed payloads containing the attacker’s fee recipient. The advisory rates the execution-client scenario very low because the Engine API usually stays on the same host or a private network.

Remaining risks and remediation steps

Teku’s release removes trust in emSign ECC Root CA - G3, emSign Root CA - G1, emSign Root CA - G2 and AAA Certificate Services. Its release notes explicitly state that the Eclipse Temurin base images do not yet include the fix, while Besu lists the same roots and identifies the G1 removal as precautionary.

Container and host runtimes need separate attention. The advisory identifies Teku images through version 26.10.2, including its alternative JDK tags, as carrying an unfixed runtime. Updating Java on the host leaves Java inside those images unchanged. Besu says its root removal applies only to Docker images, so an archive installation using a distribution or vendor JDK may still trust the roots. Teku’s binary distribution likewise uses the runtime installed by its operator.

OpenJDK’s guidance supplies a CheckCerts.java diagnostic to test runtime exposure. For standalone installations, its root-removal procedure calls for backing up the keystore, removing the relevant certificates and restarting live runtime instances. Operators must repeat the procedure for each installed runtime, as checking a different Java installation from the one running the client leaves that client’s exposure unchecked.

Operating-system packages take different paths. OpenJDK says updating system certificates is likely sufficient for distributions including Fedora and Red Hat Enterprise Linux. On Debian and Ubuntu, a bug in the Java certificate package means updating the certificate packages alone is insufficient, and the guidance requires removing and recreating the system Java keystore. FreeBSD and Homebrew runtimes do not use the system certificates and require direct package updates.

Teku also documents controls for individual connections. An external signer truststore containing only the signer’s certificate authority narrows trust for that connection, and a client keystore enables mutual authentication. Startup state, peer lists and proposer configuration can be supplied as local files. Teku has no certificate-pinning options for remote beacon, execution-client and builder connections. The advisory recommends keeping them on the same host or a private network and using local mev-boost.