Quick answer: The eMudhra certificate flaw exposed private keys for eight intermediate certificate authorities on Oct. 17, 2026. Teku 26.10.3 and Besu 26.10.2 Docker images now distrust the related roots. Default Teku mainnet nodes are not affected and no exploitation has been reported, per Teku’s advisory and CoinDesk.
The eMudhra certificate flaw has reached Ethereum. Some Teku and Besu setups could have trusted forged certificates, letting an attacker pose as a service a validator relies on and redirect its block rewards, according to Teku’s security notice and CoinDesk.
Fortunately, both client teams have shipped fixes. A default Teku node on mainnet is not affected, and no exploitation has been reported.
What happened with the eMudhra certificate flaw?
On Oct. 17, 2026, researchers showed that the private keys of eight eMudhra (emSign) intermediate certificate authorities could be worked out from their public certificates. This happened because the keys had been generated with too little randomness. eMudhra, an Indian certificate authority, revoked them on Oct. 18. Browsers, operating systems and Go blocked them soon after.
Java is the gap, though. It does not check revocation by default. So a Java program can still accept a forged certificate as genuine. Teku, a consensus client, and Besu, an execution client, both run on Java.
OpenJDK shipped two fixes. On Oct. 20 it blocked the compromised intermediates. On Oct. 23 it removed four eMudhra and Sectigo roots, per OpenJDK’s guidance.
How Teku and Besu responded
Besu released version 26.10.2 on Oct. 26 at 17:44 UTC. Teku followed with version 26.10.3 on Oct. 27 at 04:57 UTC. In both cases, the Docker images no longer trust the emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 and AAA Certificate Services roots.
However, the fix stops at the container. Operators who run the clients straight on a machine still use their own Java runtime. They must update it, or remove the roots by hand. Teku also warns that Java 26 is end of life and will get no patched build. Those operators need to move to Java 25, for example with the consensys/teku:26.10.2-jdk25 tag.
According to Teku, Consensys Diligence, its security partner, first flagged the issue.
Who is exposed to the eMudhra certificate flaw?
This is the key question for stakers. In short, Teku is affected only when it makes HTTPS connections to another host. Peer-to-peer networking does not use certificate authorities, so gossip and discovery are safe.
Moreover, the attacker needs a spot on the network path. Think shared hosting, a cloud provider, a hacked router or hostile Wi-Fi. Because anyone can derive the keys from public certificates, that network position is the only real barrier.
Teku’s notice ranks the risk by endpoint:
| Endpoint | Worst case if faked | Teku’s risk rating |
|---|---|---|
| External signer | Signed exits and fee redirects | Low to medium |
| Remote beacon node | Blocks that pay fees to the attacker | Medium |
| Checkpoint sync URL | Node starts from a fake state | Medium, startup only |
| Builder or relay | Payout swap or missed proposal | Low |
| Remote execution client | Fake payload validity | Very low |
Notably, a remote beacon node over the internet is a common setup. Meanwhile, the external signer carries the highest stakes, because a faked signer could obtain signatures for irreversible voluntary exits. Mutual TLS blocks that path.
Why the eMudhra certificate flaw matters for Ethereum
No ETH was lost. Even so, the incident shows how staking risk now reaches far beyond Ethereum’s own code. A single weak key at a certificate company in India travelled through Java and into validator software.
Also, the scale makes this worth attention. Ethereum’s staked supply sits near record highs, as we covered in our report on the 44 million ETH staking record. Many professional operators run Teku or Besu in Docker, often with remote beacon nodes or signers. In addition, the bug lands while core developers juggle a separate fix for the delayed Glamsterdam upgrade, which we tracked in our Glamsterdam delay explainer.
In the end, client diversity helped here. For example, Lighthouse, Prysm and Nimbus do not run on Java, so only Java-based setups were ever in scope. That is the practical case for running a mix of clients.
Market context
Overall, the news did not move the market on its own. ETH traded at $2,304.84 at 07:54 UTC on Oct. 29, 2026, down 2.1% over 24 hours, per CoinGecko. Bitcoin was at $79,783, down 1.4%. Both moves track the wider risk-off mood after the Fed hold, not the client patches.
What to watch next
First, look for a Teku release whose default images ship without the emSign ECC Root CA G3, which the team says is coming. Second, watch for updated Eclipse Temurin base images, since Teku says they do not include the fix yet. Finally, solo stakers on Ubuntu or Debian should note that updating packages alone is not enough. OpenJDK says they must rebuild the Java keystore.
For a wider look at how AI-found bugs are changing node security, see our Bitcoin Core security policy story.
FAQ
Is my ETH at risk from the eMudhra certificate flaw?
Only if you run Teku or Besu on an unpatched Java runtime and connect to remote services over HTTPS. A default Teku mainnet node needs no action, and no exploitation has been reported.
What should Ethereum node operators do?
First, Docker users should update to Teku 26.10.3 or Besu 26.10.2. Operators running the clients directly should update Java or remove the eMudhra roots. Finally, anyone on Java 26 should move to Java 25.
Are other Ethereum clients affected?
So far, the advisories cover Teku and Besu because both run on Java. By contrast, clients written in other languages rely on different certificate stores, and Go has already blocked the certificates.
Sources
- Teku security notice: eMudhra CA compromise
- Teku 26.10.3 release notes
- Besu 26.10.2 release notes
- OpenJDK: Compromised Certificates and OpenJDK Java Runtimes
- CoinDesk: Security failure at Indian certificate firm bites Ethereum
- CoinGecko: Ethereum price
This article is for information only and is not financial advice.
