Web3Signer security notice: eMudhra CA compromise

[usmansaleem]

Web3Signer security notice: eMudhra CA compromise

Last updated: 2026-10-27

Summary

A default Web3Signer setup is not affected and needs no action. Default here means: keys loaded from local files, a bundled network, no TLS options, and no remote key vaults. Web3Signer is affected only if you turn on one of the features listed below.

On 2026-10-17, the private keys of eight eMudhra (emSign) intermediate certificate authorities were shown to be recoverable from their public certificates. They were revoked on 2026-10-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. Anyone holding one of these keys can create a certificate that Java accepts as genuine. This includes the Eclipse Temurin runtime in the Web3Signer Docker images up to 26.10.1.

OpenJDK shipped two fixes. On 2026-10-20 it blocked the compromised intermediates and their Sectigo cross-signs (CVE-2026-91403). On 2026-10-23 it removed four eMudhra and Sectigo roots (CVE-2026-114820).

On a runtime with neither fix, Web3Signer can be exposed in two ways:

• Inbound, with no interception needed. If HTTPS client authentication accepts CA-signed clients, an attacker can create a client certificate and connect directly. This is the most serious case, because the attacker can then request signatures.
• Outbound, if an attacker can intercept traffic. When Web3Signer connects to an https:// endpoint (a key vault, a cloud key service or the downstream Ethereum node), an attacker who can intercept the traffic can impersonate that endpoint. For key vaults, that includes reading the private keys the vault returns.

Am I affected?

How exposed you are depends on how Web3Signer is configured and where it runs. Check each row:

If you use…	Why it matters	Affected?
--tls-allow-ca-clients=true	Web3Signer accepts any client certificate that chains to a root in Java's default trust store, as well as the clients in --tls-known-clients-file if that is also set.	Yes, high risk. No interception needed.
HashiCorp Vault signer configs (type: hashicorp) with tlsEnabled: true	The connection to Vault trusts Java's default roots. Setting tlsKnownServersPath does not prevent this, because certificates signed by a trusted CA are still accepted.	Yes, high risk, if an attacker can intercept traffic
Azure Key Vault (--azure-vault-enabled, or type: azure-secret / azure-key signer configs)	The Azure SDK trusts Java's default roots	Yes, high risk, if an attacker can intercept traffic
AWS Secrets Manager (--aws-secrets-enabled, or type: aws-secret signer configs)	The AWS SDK trusts Java's default roots	Yes, high risk, if an attacker can intercept traffic
GCP Secret Manager (--gcp-secrets-enabled)	The Google Cloud client trusts Java's default roots	Yes, high risk, if an attacker can intercept traffic
AWS KMS (--aws-kms-enabled, or type: aws-kms signer configs)	The AWS SDK trusts Java's default roots. Keys never leave KMS.	Yes, if an attacker can intercept traffic
eth1 with --downstream-http-tls-enabled	--downstream-http-tls-ca-auth-enabled defaults to true, so the connection to the Ethereum node trusts Java's default roots, even when --downstream-http-tls-known-servers-file is set	Yes, if an attacker can intercept traffic
eth2 --network set to an https:// URL	The network configuration is downloaded over HTTPS when Web3Signer starts. Bundled network names (such as mainnet) download nothing.	Yes, if an attacker can intercept traffic
--tls-known-clients-file only, without --tls-allow-ca-clients	Only the client certificates you listed are accepted	No
eth1 with --downstream-http-tls-known-servers-file and --downstream-http-tls-ca-auth-enabled=false	Only the server certificates you listed are accepted	No

These parts of Web3Signer are not affected:

• Keys loaded from local files (file-keystore and file-raw signer configs, --keystores-path).
• Slashing protection database: the PostgreSQL JDBC driver uses its own root certificate setting (sslrootcert), not Java's trust store.
• Prometheus metrics (--metrics-enabled): Prometheus pulls from a plain HTTP endpoint on Web3Signer. No TLS is involved.
• Metrics push (--metrics-push-enabled): it pushes over plain HTTP only.
• HTTP without TLS: no certificates are involved. Note that plain HTTP has no client authentication at all.

How your environment changes the risk

• Where the Web3Signer HTTP port can be reached. The client authentication issue only needs network access to Web3Signer's HTTP port. A port exposed to the internet, a shared VPC or a Kubernetes cluster without network policies is open to anyone who can reach it. A port bound to localhost, or behind a firewall that only admits your validator clients, greatly reduces the risk.
• Which APIs are enabled. Client authentication is the only access control on Web3Signer's HTTP API, so an attacker who passes it can use every enabled API: signing, the Key Manager API (--key-manager-api-enabled) and the Commit-Boost API (--commit-boost-api-enabled).
• Network path for outbound connections. Intercepting traffic needs a position on the path, such as shared hosting, a cloud provider, a compromised router or a hostile Wi-Fi network. A signer in a controlled data centre is less exposed than one on shared infrastructure.
• How Java was installed.
  • Docker images up to 26.10.1: both ship Eclipse Temurin. The default image's trust store has the emSign ECC Root CA - G3 root but no AAA Certificate Services root. The distroless image's trust store has both.
  • Oracle and OpenJDK builds: they include both roots.
  • Ubuntu and Debian packages: Java uses /etc/ssl/certs/java/cacerts, which takes extra steps to update (Debian bug 1069251).
  • RHEL, Fedora and others: Java uses the operating system's certificate store.

What an attacker could do

Endpoint	Worst case
Web3Signer HTTP API with --tls-allow-ca-clients=true	Request signatures with your keys. For eth2 keys: voluntary exits (irreversible) and builder registrations that redirect fees. If slashing protection is disabled, slashable blocks and attestations too. For eth1 keys: sign and send transactions that move funds. With the Key Manager API enabled: delete or import keys.
HashiCorp Vault, Azure Key Vault secrets, AWS Secrets Manager, GCP Secret Manager	Read the private keys the vault returns. Stolen keys can then be used for anything, including slashable messages. Also capture the credentials Web3Signer sends (Vault token, Azure or GCP access token, Azure client secret) and use them against the vault directly.
Azure Key Vault keys (azure-key)	Capture the access token, and the client secret if you use client-secret authentication, and use them to sign with the key directly until the token expires or the secret is rotated.
AWS KMS	Return invalid signatures or refuse requests, so duties are missed. The keys stay in KMS, and AWS request signing does not expose reusable credentials.
Downstream Ethereum node (eth1)	Read, drop or answer the JSON-RPC requests Web3Signer forwards, including returning false nonces so transactions get stuck. Transactions are signed by Web3Signer, so the attacker cannot change them.
Network configuration URL	Make Web3Signer use an attacker-chosen network configuration, so it produces signatures that are invalid on the real network.

No exploitation has been reported.

How to reduce exposure in Web3Signer

Inbound client authentication: remove the CA flag

Remove --tls-allow-ca-clients and list your validator clients' certificate fingerprints in --tls-known-clients-file. This fixes the issue, regardless of the roots Java trusts. If you must keep the flag, also fix your Java runtime as described below.

Restrict outbound trust where Web3Signer supports it

These settings protect a connection whatever roots Java trusts:

• Downstream Ethereum node (eth1): set --downstream-http-tls-known-servers-file to your node's certificate fingerprint and --downstream-http-tls-ca-auth-enabled=false.
• Network configuration: download the file yourself and pass a local path to --network.

How to fix your Java runtime

Docker image users: upgrade

Upgrade to the next Web3Signer release after 26.10.1. Both images (consensys/web3signer:26.10.2 and consensys/web3signer:26.10.2-distroless) will ship Eclipse Temurin 25.0.5+8. That build no longer has the emSign ECC Root CA - G3 root and does not include AAA Certificate Services. We tested both images: they reject all 12 test chains published at emudhra.we-have-a-problem.com (#1267). Your existing arguments, volumes and ports stay the same.

Both commands should print Temurin-25.0.5+8 or later:

docker run --rm --entrypoint java consensys/web3signer:26.10.2 --version
docker run --rm --entrypoint java consensys/web3signer:26.10.2-distroless --version

Binary distribution users

The .tar.gz and .zip distributions run on the Java installed on the host. We recommend you follow the official CVE guidance for checking if you are vulnerable and fixing:

• OpenJDK guidance - https://openjdk.org/emudhra
  • OpenJDK vulnerability advisory, 2026-10-21: CVE-2026-91403
  • OpenJDK vulnerability advisory, 2026-10-24: CVE-2026-114820
• Oracle guidance - https://ops.java/emudhra
  • Oracle Security Alert Advisory: CVE-2026-91403
  • Oracle Security Alert Advisory: CVE-2026-114820

After changing the Java runtime or its trust store, restart Web3Signer, because a running process keeps the old trust store. Then check the logs to confirm that Web3Signer still loads keys from each vault, reaches the downstream node, and accepts connections from your validator clients.

What the Web3Signer team is doing

The next Web3Signer release updates both Docker images to Eclipse Temurin 25.0.5+8 (#1267). We will update this notice when that release is published. Binary distributions use the host's Java, so follow the Java runtime guidance above.

Special Thanks

Thanks to Consensys Diligence, our security partner, for flagging this issue.

References

• OpenJDK: guidance on the eMudhra certificates
• OpenJDK vulnerability advisory, 2026-10-21: CVE-2026-91403
• OpenJDK vulnerability advisory, 2026-10-24: CVE-2026-114820
• OpenJDK CheckCerts.java diagnostic
• Oracle: guidance on the eMudhra certificates
• Oracle Security Alert Advisory: CVE-2026-91403
• Oracle Security Alert Advisory: CVE-2026-114820
• Mozilla bug 2083449: the incident record; comment 18 keeps emSign Root CA - G1 trusted
• eMudhra statement on the incident
• Eclipse Temurin trust store update
• Eclipse Temurin October 2026 release status
• Ubuntu: eMudhra CA compromise fixes available: fixed ca-certificates versions and the Java trust store rebuild
• Debian bug 1069251: why ca-certificates-java updates don't refresh Java's trust store