The underlying compromise concerns eight intermediate certificate authorities—issuers that can create certificates under a trusted chain. In Mozilla’s incident record, Dennis Jackson said Mozilla independently recovered their private keys. eMudhra says the affected intermediates had not issued publicly trusted end-entity certificates and its infrastructure and customer data were not compromised.
Signing Requests and Node Access
Web3Signer’s notice identifies its highest-risk inbound configuration as `--tls-allow-ca-clients=true` on an unpatched runtime. An attacker who can reach the signing service can forge a client certificate and request signatures without intercepting another connection.
For validator keys, the team says that could mean irreversible voluntary exits or builder registrations that redirect fees. Slashable blocks and attestations are also possible if slashing protection is disabled. For transaction-signing keys, an attacker could request transactions that move funds.
The immediate remedy is to remove `--tls-allow-ca-clients` and list trusted validator-client certificate fingerprints in `--tls-known-clients-file`. The notice says this fixes the inbound issue regardless of Java’s trusted roots.
Outbound connections create a separate risk. An attacker able to intercept Web3Signer’s HTTPS traffic to supported secret-management services could read private keys returned by those services and capture credentials. AWS KMS is different: its keys never leave KMS, and the notice describes invalid signatures or refused requests rather than key theft.
Teku’s notice calls the external signer its highest-risk HTTPS endpoint. It recommends a dedicated trust store containing only the signer’s CA, plus mutual TLS: Teku presents a client certificate and the signer accepts only known clients. The team says requiring that client certificate prevents an impersonator from relaying requests to the signer, limiting the impact to denial of service.
Teku’s other exposed HTTPS connections include remote beacon nodes, execution clients, builders and startup-data sources. Unlike Besu and Web3Signer, Teku does not accept client certificates on its APIs, so its notice identifies no inbound exposure. It recommends local files for startup data and proposer configuration, and local or private-network connections for remote nodes and builders where certificate pinning is unavailable.
Besu’s report flags `--rpc-http-tls-ca-clients-enabled` as its highest-risk setting. On an unpatched runtime, a reachable attacker can bypass certificate-based client authentication; separate API authentication and the Engine API’s default JWT requirement still apply. Operators should remove that flag and explicitly list trusted clients or use a trust store containing only their own CA.
Besu also identifies interception risks for HTTPS history downloads, remotely fetched bootnode lists and some telemetry connections. Its peer-to-peer networking and default JWT-authenticated Engine API are unaffected.
Fix the Java Runtime Inside the Container
The three teams direct operators to OpenJDK’s remediation guidance, which provides a diagnostic program and recommends installing a runtime whose release notes identify the certificate fix. Alternatives include removing specified roots or enabling revocation checking. Running Java processes must be restarted after trust-store changes. Debian and Ubuntu packages require an additional Java-keystore rebuild even after certificate packages are updated.
The distinction between host and application updates also featured in The Defiant’s earlier coverage of Lightning Labs’ response. Its Taproot Assets release rebuilt binaries with patched Go; these notices instead focus on Java runtimes and connection configuration.
Teku says all Docker images through 26.10.2, including its `-jdk25` and `-jdk26` tags, lack the fixes. Updating the host’s Java does not update the container. It recommends moving from the default Java 26 images to `-jdk25` tags because Java 26 is no longer supported, but that switch alone does not remove the affected root from the existing images.
Besu and Teku say fixed Docker releases are forthcoming. Web3Signer says the release after 26.10.1 will ship Eclipse Temurin 25.0.5+8 in both images. Its Docker update has been merged; the team reports that replacement images rejected all 12 published compromised-certificate test chains, compared with six accepted by the old default image.
thedefiant.io
