Skip to content
Prices
  • BTC$80,333▲ 0.11%
  • ETH$2,328▲ 0.14%
  • BNB$738.33▲ 0.07%
  • XRP$1.29▼ 0.23%
  • SOL$101.46▲ 0.81%
  • TRX$0.3306▲ 0.58%
  • HYPE$77.11▲ 2.05%
  • DOGE$0.0771▲ 0.87%
  • LINK$11.45▲ 1.18%
  • ADA$0.2044▲ 0.57%
  • AVAX$8.94▲ 1.91%

Consensys warns Besu, Web3Signer operators over eMudhra keys

Default Besu and Web3Signer setups are safe, Consensys says, but Java runtimes still trusting eMudhra's cracked keys leave some Ethereum node configs exposed.

· · 2 min read

Share
A server rack with network equipment and a monitor on top in a utility room (illustrative photo)
Image: Tony Webster / Wikimedia Commons, CC BY 2.0
On this page

Consensys has warned Ethereum node operators that some setups of its Besu execution client and Web3Signer remote signer can still be fooled by certificates made with eMudhra's compromised keys, The Defiant reports. Default installations are not affected, the teams say, but certain configurations need changes now.

This is a follow-up to the eMudhra certificate compromise, in which eight intermediate keys of the Indian certificate authority turned out to be trivially weak.

Why Java is the weak spot

  • Besu and Web3Signer are written in Java, and their Docker images bundle the Eclipse Temurin runtime.
  • Java ships its own list of trusted root certificates and, by default, does not check whether a certificate has been revoked. Browsers blocked the bad eMudhra intermediates within days; a Java runtime without the October OpenJDK fixes (CVE-2026-91403 and CVE-2026-114820) can still accept them, according to a summary of the notices on the incident tracker pwn.watch.

Which setups are exposed

  • High risk: Besu nodes started with --rpc-http-tls-ca-clients-enabled, which lets any client with a CA-signed certificate use the JSON-RPC API. An attacker can mint such a certificate without intercepting any traffic.
  • Interception risk: features that fetch data over https:// or wss://, such as ERA1 history import, HTTPS bootnodes, ethstats, OpenTelemetry and Pyroscope, and remote key vaults used by Web3Signer, could be impersonated by someone able to sit on the network path.
  • Web3Signer access control: operators who let clients in with --tls-allow-ca-clients or --tls-allow-any-client are told to switch to an explicit --tls-known-clients-file list. A remote signer holds validator keys, so who may talk to it matters.

What operators should do

  1. Update the Java runtime (or the client image) to a build with the eMudhra fixes.
  2. If that is not possible yet, remove the eMudhra roots from the runtime's cacerts store or turn on revocation checking, as Oracle's own guidance describes.
  3. Replace CA-based client trust with a known-clients file and keep RPC and signer ports off the public internet.

Home stakers running default settings do not need to panic; this is the kind of maintenance covered in our guide to crypto staking. eMudhra, for its part, has apologised, saying a script error caused the weak keys, and promised an independent review and a public root-cause report.

This article is for information only and is not financial advice. Crypto assets are volatile; do your own research. Read our disclaimer

Share

More from Security

View all →

Read next