Teku and Besu patch Ethereum flaw tied to eMudhra certificates
Ethereum $2,319▼ −2.12% 24has of Oct 29, 2026, 6:00 AM ET
Ethereum clients Teku and Besu released fixes after weak eMudhra certificate keys left some validator setups trusting forged certificates.
Key points
- Teku 26.10.3 and Besu 26.10.2 fix trust in forged eMudhra certificates
- Default Teku mainnet nodes were not affected; no exploitation reported
- Risk centered on external signers and HTTPS links without client certificates
- Java 26 is end of life with no patch; CoinDesk says move to Java 25
Developers of the Ethereum clients Teku and Besu have released patches after a key-generation failure at Indian certificate authority eMudhra left some validator setups trusting forged certificates, CoinDesk reported on Oct. 29. Default Teku mainnet nodes were not affected, and no exploitation has been reported, according to the report.
How the eMudhra key failure reached Ethereum clients
CoinDesk said researchers found on Oct. 17 that the private keys behind eight eMudhra intermediate certificate authorities had been generated with too little randomness, meaning the keys could be derived from the public certificates. Browsers blocked the certificates, and eMudhra revoked them a day later. CoinDesk also reported that the company has said it will exit the certificate business.
The Ethereum exposure stems from how Java handles revocation. Java does not check revocation by default, so Teku’s Docker images kept trusting the compromised certificates, according to CoinDesk. Teku and Besu both run on Java.
An attacker positioned between a validator and a service it connects to could impersonate that service and redirect block fees, CoinDesk reported. A fake external signer could also supply signatures that change where rewards are sent. Teku ranked that external-signer scenario as the riskiest configuration, the report said.
Which setups are affected
Teku’s security notice, last updated Oct. 26, says a default mainnet node is not affected and needs no action. The notice says Teku is exposed only when it makes HTTPS connections to a host, and it recommends configuring client certificates for external signers. It adds that Teku accepts no client certificates on its APIs, so there is no inbound exposure. The notice points operators to OpenJDK advisories and Oracle guidance for updating the Java runtime.
CoinDesk said Consensys Diligence, Teku’s security partner, first flagged the issue.
Fixes and what operators should do
According to CoinDesk, the fixes are Teku 26.10.3, released Tuesday, and Besu 26.10.2, released Monday. Operators who run the clients in Docker should pull the latest images. Those running directly on a host must update Java separately, the report said. Java 26 has reached end of life with no patched build, so CoinDesk said users of that version should move to Java 25.
The wider eMudhra incident has drawn responses beyond crypto. Indian outlets and security publications have reported that Google and Mozilla distrusted the affected certificates, and that India’s CERT-In issued an advisory on Oct. 21 urging organizations to update browsers and trust stores and review services relying on the certificates. eMudhra has said its Indian digital signature and eSign services were not affected, according to those reports.
The Teku notice and CoinDesk’s account both describe the risk as conditional on specific configurations, mainly connections to remote services or external signers that do not use client certificates. Validator operators with such setups can check the Teku and Besu release pages for the patched versions.