Teku warned Ethereum validators that compromised eMudhra certificate keys could let attackers impersonate HTTPS endpoints, but default mainnet nodes are safe.
Key Facts
The team behind Ethereum consensus client Teku warned that compromised keys from eight eMudhra intermediate certificate authorities could let an attacker who can intercept traffic impersonate HTTPS endpoints Teku connects to on Java runtimes without OpenJDK's fixes.
A default Teku node on mainnet with no HTTPS URLs in its configuration is not affected, and no exploitation has been reported, according to the notice.
Every Teku Docker image up to and including version 26.10.2 ships a Java runtime without either OpenJDK fix, the team said.
The issue matters for operators who point Teku at HTTPS endpoints such as remote signers or beacon nodes on a Java runtime without the fixes.
What Happened With the eMudhra Certificates
On Oct. 17, the private keys of eight eMudhra (emSign) intermediate certificate authorities were shown to be recoverable from their public certificates, according to the notice. They were revoked on Oct. 18, and browsers, operating systems and Go have since blocked them.
Java does not check revocation by default, so Java runtimes need their own fix. OpenJDK shipped two, on Oct. 20 and Oct. 23.
On a runtime with neither fix, an attacker who can intercept Teku's traffic can impersonate an HTTPS endpoint it connects to.
"Anyone can derive the compromised keys from the public certificates, so that network position is the only real barrier," the team said. "No exploitation has been reported."
Which Teku Validators Are at Risk
The external signer is the highest-risk endpoint. An attacker impersonating it could obtain signatures for voluntary exits, which are irreversible, or for builder registrations that redirect fees, as well as slashable signatures if the signer's own slashing protection is off, the notice said.
A signer that requires a client certificate from Teku limits the impact to a denial of service.
Every Teku Docker image up to and including 26.10.2, including the -jdk25 and -jdk26 tags, ships a Java runtime with neither fix, so Docker users who rely on any affected option remain exposed until a fixed image is released.
The team also told them to move to the -jdk25 tags, since Java 26 is end of life and no fixed Java 26 build is coming.
