Teku and Besu teams have issued updates to stop attackers using forged certificates to redirect block fees in some custom Ethereum setups. The required fix depends on whether operators use a supplied Docker package or a separate Java installation.
Teku and Besu teams have released security updates for Ethereum nodes after an eMudhra certificate issue affected some custom configurations. Besu 26.10.2, released on October 26, and Teku 26.10.3, released on October 27, remove four root certificates from their supplied Docker packages. Operators installing the client from an archive may also need to fix the Java runtime that runs it.
According to the Teku security advisory updated on October 28 and Besu incident report, default mainnet configurations are unaffected. The risk arises when operators use particular HTTPS connections or certificate-based access settings. Neither team reports known exploitation in its advisory, a confirmed ETH loss or an affected operator count.
What could a forged certificate allow?
Teku handles Ethereum consensus and validator duties, while Besu is one of the clients that execute transactions. Both run on Java. A TLS certificate authenticates the server at the other end of an HTTPS connection; that check is separate from the network rules used to validate Ethereum blocks.
Teku’s team identifies the HTTPS connection to an external signer as the greatest risk. That service holds the validator’s private keys on a separate system and produces a digital signature for each requested message. An attacker would first need to intercept the network connection. By impersonating the signer with a forged certificate, the attacker could obtain a signature for an irreversible voluntary exit or a registration directing block fees to another recipient.
An attacker could obtain conflicting signatures that trigger a slashing penalty against staked ETH only if the signer’s own protection against double signing is disabled. Mutual TLS, in which both sides authenticate with certificates, limits the external signer scenario described in the advisory to denial of service. Teku's own slashing protection remains active in the separate scenario involving a forged remote beacon node.
An attacker impersonating a remote node, builder or relay could send incorrect block data, cause missed duties or withhold block contents. If Teku reads the fee recipient from an HTTPS address, the attacker could substitute another recipient when those settings refresh. A local mev-boost service also checks the public keys of the relays it connects to.
Why is Besu's optional access setting different?
An attacker could bypass Besu’s certificate check if an operator enables “--rpc-http-tls-ca-clients-enabled” and verifies connecting applications against Java’s default root certificates. Network interception is not required in that case; being able to reach the relevant RPC or Engine API endpoint, where applications send requests to the node, may be enough.
The consequences depend on which API functions are enabled. If separate user authentication or JWT credentials are required, the attacker still needs them. The shared JWT secret used by the default Engine API is unaffected. Configurations accepting only specified clients or using a private certificate authority remain protected, provided the operator has not copied the affected Java roots into their certificate store.
To impersonate services reached through certain outbound HTTPS or WSS connections from Besu, an attacker must intercept the traffic, as in the Teku scenarios. The report lists optional ERA1 history imports, remote bootnode lists and certain monitoring connections. ERA1 imports are disabled by default. Imported blocks are still validated from genesis, so forged history does not automatically become a valid alternative chain.
The mainnet exception does not extend to every testnet installation. When starting with an empty database on Sepolia, Hoodi or Ephemery, Teku can download a startup file over HTTPS by default. Using a trusted local file or connecting to an external signer through the operator’s private certificate authority are among the mitigations listed in the advisory.
How do the Docker and Java updates differ?
| Installation | Scope of the update |
|---|---|
| Supplied Teku Docker package | 26.10.3 removes four root certificates from the Java store inside the package. |
| Supplied Besu Docker package | 26.10.2 removes the same four roots from the Java store inside the package. |
| Client installed from an archive | The operator must check their Java installation and apply the required fix separately. |
The removed roots are emSign ECC Root CA–G3, emSign Root CA–G1, emSign Root CA–G2 and AAA Certificate Services. The last certificate is included because cross-signing can let the same certificates be accepted through another root. Teku's earlier 26.10.2 Docker package does not contain the fix even if it carries a Java 25 or 26 label. Updating Java on the host also does not change the separate runtime inside a container.
In its October 24 guidance, OpenJDK’s team recommends moving to a Java vendor’s fixed release. Alternatives include backing up the certificate store, removing the relevant roots and restarting all Java processes. A major version number alone is not enough: operators need to check the distribution, update build and certificate store actually loaded.
Teku’s team says Java 26 reached the end of support in September and is not expected to receive a fixed build. It recommends Java 25, which receives long-term support (LTS). OpenJDK warns that updating system certificate packages on Debian or Ubuntu does not always refresh Java's cached store. Operators need to follow the instructions for their own distribution.
eMudhra revoked eight intermediate certificates
According to eMudhra’s statement updated on October 28, a key-generation error made private keys for eight intermediate certificates recoverable from the public certificates. The company says it was notified on October 17 and revoked them on October 18, within 14 hours of confirming the problem. It also says no end-user certificates were issued from those eight intermediates and that its infrastructure and customer data were not compromised.
Java applications can continue accepting revoked TLS certificates because Java does not check revocation by default. The approximately 30,800 certificates mentioned in eMudhra's October 28 update belong to the wider G3 hierarchy used by its US customers. They are not certificates issued from the eight affected intermediates or a count of Ethereum validators.
The company plans to move customers temporarily to an alternative chain based on its G1 root, then stop issuing publicly trusted TLS certificates once the transition is complete. It says its other electronic signature and enterprise certificate services will continue. Teku and Besu’s peer-to-peer networking does not rely on these certificate authorities. The teams ask operators to fix the relevant Java installation and connection settings; they do not recommend disabling HTTPS.
Teku’s team announced version 26.10.3 and linked its security advisory on October 27 at 05:01 UTC.
Teku’s October 27 security update announcement
The post loads from X when you open it.
