Teku and Besu updated their respective Docker images after the eMudhra incident, as weak certificate keys posed a risk to software that connects to external services, including some Ethereum validators deployed as well.

• Teku On 26.10.3 and Besu on 26.10.2, the affected certificate trust was removed from the Docker image due to the eMudhra incident.
• Teku indicates that, by default, the mainnet nodes are not affected. The actual degree of exposure depends on the HTTPS connections and the Java runtime used by the operator.
• The disclosed risks involve services and verifier operations that are impersonated; there were no reports of such exploitation in the notifications from Teku.

For operators, the most immediate issue at present is: when connecting to other services, whether their software will accept forged certificates. The answer depends on the connection used and the installation of Java; therefore, a client update does not mean that every verifier faces the same risk.

Teku and Besu updating Docker image

The Ethereum client team has released an update to fix a certificate issue that originated outside of the blockchain. The relevant changes involve how the software determines whether remote services are authentic.

Teku on 26.10.3 and Besu on 26.10.2 have removed trust in the affected certificate roots from their Docker images. This release is due to the discovery of weak keys related to the certificate issuing authority eMudhra.

For verifier operators, the issue lies in attackers impersonating the services that the software connects to. Depending on the role of those services, forging responses may disrupt responsibilities or affect the payment destinations of certain block fees.

But this does not mean that every Ethereum validator is at risk. A security notice from Teku states that default mainnet nodes are not affected, and so far, there have been no reports of any exploits.

The difference lies in the installation method. Operators using external HTTPS services need to check for connections that may not exist in fully localized component deployments.

These updates are applicable to specific installation environments. The patched Docker image contains runtime modifications packaged within the container, whereas software installed from archived files may use a different Java provided by the operator.

This incident affected the infrastructure surrounding the verifiers, but Ethereum's consensus rules have not changed.

Why can certificate issues evolve into security risks?

Certificates help software determine whether it is connected to the expected service. Trusted certificate authorities provide endorsement for the identity corresponding to the server certificates.

This mechanism is very common on HTTPS websites, but it is also applicable in applications that do not communicate through browsers. Backend services may also rely on these identity verifications.

Certification authorities may use intermediate certificates under trusted root certificates. The private keys associated with these intermediate certificates must be kept secure, as they can be used to issue more certificates.

In this incident, the problem is not just that someone obtained the ordinary login information from the server. The affected intermediate keys can be recovered from the information that has already been made public.

According to the explanation from the security team at Go, this vulnerability allows for the recovery of private keys on a microsecond level. The description also indicates that attackers could subsequently create certificates for domain names that they do not have control over.

If a vulnerable application believes that the certificate can ultimately be traced back to an institution it trusts, it may accept it. In this way, impersonation attempts that are intended to deceive others could pass the checks that are originally designed to reject such fraudsters.

However, attackers still need some way to intercept or redirect the victims' connections. Weak keys will not automatically allow them to appear between each user and each server.

This condition narrows down the ways in which attacks can occur, but it does not make it harmless to invalidate a certificate. As long as the software treats the impostor as a legitimate endpoint, network interception becomes even more dangerous.

The research by Kudelski Security examined the levels of certificates that were affected. The issue is that the software may accept certificates issued by keys that can be reproduced by attackers.

eMudhra attributes weak keys to processing errors

According to the event statement from eMudhra, a researcher reported 8 weak intermediate keys on October 17th. The company revoked these 8 keys the following day.

The company stated that these intermediate certificates were generated during a key ceremony on April 30, 2025. According to the company, the defective steps wrap and unwrap produced weak copies in addition to the original strong keys.

The company stated that it used certified hardware security modules. It attributed the failure to a certain step in the surrounding processes, rather than a lack of such devices.

The company also stated that 7 of the intermediate certificates were never used in a production environment, and the remaining 1 certificate has not yet been issued. The company claimed that this incident did not result in any intrusion into their infrastructure or data leakage.

These explanations clarify the description of eMudhra regarding its internal workings. However, software providers still need to consider another possibility: other parties may utilize recoverable keys.

The certificate system cannot rely solely on the original operator's promise not to issue any further content. Once someone else is able to reproduce a certain signature key, such a guarantee can no longer control all possible certificates that might be created.

Therefore, the response measures go beyond the company that generated the keys. Browser manufacturers, operating system providers, and programming language teams all need to consider what their users' software will accept.

These fixes will be delivered to users through various updates. Browsers may receive a blocklist, while another independent Java application may continue to use the old set of trusted certificates.

A weak key and the application that uses that key are two different aspects of the same issue. Revoking a certificate addresses the problem at the institutional record level, but clients still need a reliable way to identify the trusted paths that they should reject as being affected.

External services pose different risks to verifiers.

Ethereum nodes are composed of software that performs different functions. Ethereum client documentation distinguishes between execution clients and consensus clients: the former handles transaction execution and state management, while the latter follow a proof-of-stake consensus mechanism.

The verifier software adds the responsibility of proposing blocks and proving the chain. Operators can run these components locally, or they can connect to a portion of them through external services.

Teku is the consensus client, and Besu is the execution client. Both use Java, which is also why the certificate trust during runtime is related to their issuance.

Services outside of the local machine will add an additional layer of identity verification for this arrangement. The software needs to confirm that the endpoint responding to the request is indeed the expected provider.

For example, operators may use remote signing services instead of keeping the signing operations within the same process. Some may also rely on external endpoints to provide data or block construction services.

The extent of damage that impersonators can cause depends on what activities are permitted for that service. Services that only receive monitoring data pose a different risk from those that provide information involved in signing decisions.

Network paths are equally important. Connections that traverse public infrastructure have a different chance of being intercepted compared to those that are limited to components within the same host or a strictly controlled virtual private network.

A virtual private cloud (VPC) cannot prevent all failures from occurring, but it can reduce the chances of attackers gaining access to the traffic they need to cause interference.

Therefore, it is not possible to determine whether exposure has occurred based solely on the client name. The same software can be deployed in environments that use different endpoints, trust libraries, and access controls.

The real question that needs to be answered is: which connection accepted the certificate through the affected path. Once this is clarified, operators can assess what level of permission the impersonated service should have had in the operation of the verifier.

Why are Docker images different from archived installations?

The Docker image will package the application along with the environment required for its operation, which may include the Java runtime and the certificates trusted by that runtime.

Updating Java on the host will not automatically replace Java in the existing images. Containers may still continue to use their own packaged files.

This is the reason why the client release notes specifically mention the change of Docker. The notes for Teku state that its Eclipse Temurin base image did not yet include the relevant removal at that time, therefore the client image was modified directly.

The release note for Besu also indicates that the removal of its certificate applies to the Docker image, and it explicitly requires users who perform archived installations to check the Java release version they provide themselves.

Archiving and installation will leave this responsibility to the operators. Ethereum clients may have been updated, but their individual runtimes may still contain old certificate stores.

Conversely, similar distinctions can also arise during maintenance processes. Replacing the host runtime will affect the processes that use that runtime, but it will not impact installations that use a different Java path.

Oracle recommends that users update the affected runtime or follow the alternative solutions provided in their documentation. It also requires restarting the running instances, with each independent installation being considered separately.

This makes the running processes more important than the downloaded updates. The server may contain patched files, but the old processes will continue to run until they are replaced or restarted.

There is another variation in custom certificate storage. A certain organization may use a certificate library maintained for its own services, rather than the certificate library provided by default with Java.

The actual task is to figure out what the client is actually using. The installation method, runtime location, and trust configuration together determine whether the released fix has reached the connection that needs it.

Differences in revocation checks across different applications

Revocation means that the certificate should no longer be accepted. However, this does not guarantee that every application will check the latest revocation information before establishing a connection.

Different applications obtain this information in different ways. Some query online services, some use blocklists provided by suppliers, while others rely primarily on certificates in local trust libraries.

The response from the Go team explains why direct intervention from the runtime provider may be necessary. The team launched an emergency security release on October 19th and stated that they provided a patched version within about 7.5 hours of receiving the notification.

This action blocks the affected certificate paths involved in applications that use the relevant Go verification behavior. Java users, on the other hand, need to be protected through their own runtime and trust settings.

A notification from Teku states that Java does not check for revocation by default. This is also why it is still necessary to remove the trust locally even though eMudhra has revoked these intermediate certificates.

The removal of root certificates and the blocking of intermediate certificates can also have effects at different levels. The former rejects a specific compromised path, while the latter can block a broader chain of certificates that lead to the removed root certificate.

The correct implementation lies with the supplier and the organization that maintains the application. If a temporary measure of disabling identity verification is taken, it will only remove the protection, not solve the trust issue.

Even legitimate services may need to be adjusted. If their certificates rely on paths that the client currently rejects, then the service providers must offer acceptable alternatives, rather than expecting users to restore an insecure level of trust.

This also explains why a single certificate issue can last for several days. The discovery may be immediate, but the protections are implemented gradually through different release and maintenance processes for browsers, packaged applications, and private infrastructure.

For verifier operators, the key result is whether the relevant connections have already rejected untrusted identities. Revocation announcements from other parts of the software ecosystem do not prove that their node processes have achieved this result.

Are rewards and verifiers' stakes exposed in the same way?

The staking, signing responsibilities, and fee payments of verifiers are interrelated, but they are governed by different mechanisms. Issues that affect one of these aspects should not be automatically considered as a control over all of them.

Ethereum staking documentation explains that verifiers receive rewards for fulfilling their duties and may be penalized for offline behavior or proven misconduct. Signature permissions and withdrawal permissions play different roles within the system.

The certificate key belongs to the identity system used for connection. It is not the private signing key of the verifier, nor will it directly disclose the credentials required to manage the withdrawal of ETH.

However, the services that are impersonated may still affect the behavior of verifiers. The impact depends on which requests or responses those services handle, as well as what additional checks are still in place.

The block proposal includes the recipient of the fees related to the execution of the payment. If a certain path allows for modification of the proposal or configuration, it may have consequences without the need to control the entire stakeholding.

Signature services present another set of challenges, as they are involved in authorizing the behavior of verifiers. Their own protective measures, including restrictions on requests and safeguards against conflicting signatures, all affect to what extent attackers can succeed.

A possible consequence of service interruptions is the omission of responsibilities. Even if no payments are successfully transferred, attackers can still reduce the rewards by simply preventing proper responses.

The financial impacts of these outcomes are not the same. Missing out on proposed block opportunities, ordinary offline penalties, and reduced sanctions should not be confused with each other.

The client announcement describes the possible consequences under affected configurations, but it does not prove that every operator encountered these consequences, nor does it prove that a corresponding number of ETH were stolen.

For holders who use staking service providers, what is truly relevant is the actual deployment of those providers. Managing a certain amount of ETH does not indicate which remote services or certificate libraries the operators are using.

Verifiers also rely on software other than Ethereum.

Ethereum network rules are just one part of what operators rely on. Hardware, runtime, hosting, configuration, and external services all affect whether validators can perform their duties correctly.

The certificate issuing authority is located outside of the Ethereum protocol, but its failure becomes relevant when verifier software relies on it to identify services. This alone is sufficient to introduce a common internet security issue into the staking infrastructure.

Client diversity still holds value, as different implementations can reduce reliance on a single codebase. However, this does not mean that each dependency is independent.

Two clients can use the same programming language runtime. Different operators may also use the same hosting service provider, signature service, or blockchain infrastructure construction services.

These shared components will form a common exposed surface under different circumstances of the Ethereum software itself. Therefore, to understand the deployment situation, one cannot simply look at the number of client brands.

Outsourcing also comes with trade-offs. Dedicated signature services may improve the way keys are protected, but they also make the authentication connections to those services more important.

Local operation also has its own maintenance requirements. Placing components on the same machine can reduce some network exposure, but operators still need to manage software updates and access to that machine.

This incident does not automatically provide the safest architecture in all circumstances. What it illustrates is that it is necessary to understand and maintain the responsibilities surrounding each connection.

This distinction is also important for ordinary ETH users. The certificate patches in the node infrastructure do not mean that each wallet must transfer funds, nor do they imply any change to the balance of Ethereum accounts.

The relevant actions are to be taken by the operators of the affected software. Only they have the capability to identify the involved runtime, endpoints, and trust settings, and then apply the relevant guidance from the suppliers to the systems that are establishing these connections.

Operators need to apply and check the updates.

These provide operators with a method to remove affected trusted paths from the supported Docker images. Archiving users, on the other hand, need to handle separate runtime tasks according to the guidance of their respective Java providers.

Having patches available is just the first step in the process. The updated environment still needs to be actually put into operation, and it is necessary to ensure that the expected configurations and services are functioning properly.

For service providers, interruptions caused by recently rejected certificates may require the replacement of certificates at the endpoints. When restoring services, identity verification should be retained rather than bypassed.

Subsequent disclosures may further refine the impact. Operators may identify configurations that have adopted affected certificate chains, or report incidents involving specific services.

For now, the notification reports from Teku have not been utilized, and a distinction has been made between the use of the default mainnet and the affected external connections. This represents the clearest evidence describing the current exposure of Ethereum.

Affected operators have reason to update their systems. Any financial loss depends on which service the attacker impersonated, whether traffic was intercepted, and what actions the verifier allowed that service to perform.

What needs attention?

• Client Update: Follow the releases of Teku and Besu, and ensure that you are using the patched versions.
• Java Certificates: Refer to the vendor guidelines for each Java runtime and certificate library used in the installation.
• External link: Review the HTTPS links that point to remote signature, data, and block construction services.
• Security Notice: Pay attention to the confirmations of attacks or further explanations issued by the client team and Java supplier.

Frequently Asked Questions

eMudhra What is the event?

This incident involves weak private keys related to the intermediate certificates of the certificate issuing authority eMudhra. Researchers have found that these keys can be recovered from public information, which may allow others to create domain name certificates that they do not control. Software that trusts the affected certificate paths may accept such forged identities. Attackers still need some means to intercept or redirect connections in order to impersonate the target services.

Has Ethereum’s consensus mechanism failed?

No. The issues mentioned in the report concern how software verifies the identity of external services, rather than the consensus rules established on Ethereum’s blockchain. Client updates change the certificate trust within the affected software environments. If some validators are deployed in such a way that they can be impersonated by external services, they may still face operational risks. This possibility depends on the connections and service roles involved and does not imply that Ethereum’s consensus rules have been violated.

Which clients have been updated?

Teku on 26.10.3 and Besu on 26.10.2 modified their Docker images to remove the affected certificate trust. Teku is the consensus client, and Besu is the execution client; both use Java. The installation method is important as this change applies to the environment provided by these images. Operators who install the client archive and provide their own Java runtime need to refer to the separate guidelines for that runtime.

Will all verifiers be affected?

No. According to the notice from Teku, the mainnet nodes are not affected by default. The risk depends on whether a certain deployment has made relevant external HTTPS connections and whether its certificate checks accept the affected trust paths. Different operators can run the same client under different services, Java versions, and certificate libraries. Therefore, the name of the client or the number of ETH staked does not indicate whether a particular verifier is exposed.

Docker Can the update overwrite all installation methods?

Not possible. The patched Docker image will update the environment packaged within that image, but archived installations may use a different Java provided by the operator. Other containers or services may also have their own runtimes. Operators need to identify which installation method is being used by the running processes and follow the instructions provided by their suppliers. Files on the server that have been patched cannot protect processes that are still running in the old environment.

Has it been confirmed that it is being exploited?

At the time point mentioned in this article, there were no reports of Teku notifications being exploited. The relevant disclosures described a vulnerability and its potential consequences, but they did not prove that attackers had already utilized it against verifiers. This distinction is important when discussing potential losses. The existence of a possible path to impersonate the service does not equate to the manipulation of signing responsibilities, the diversion of fees, or the theft of ETH.

Will verifiers' deposits be automatically exposed?

No. The certificate signing key is different from the verifier's signing key, as well as from the credentials that control withdrawals. Restoring the affected certificate key will not automatically reveal the key required to withdraw the pledged ETH. The service that has been impersonated may still disrupt responsibilities or affect the information used by the verifiers, depending on the deployment method. The possible consequences should be assessed for that service, rather than considering it as an automatic access to the entire deposit.

What should operators do?

Operators should follow the relevant Teku or Besu release notes, as well as the guidelines for their Java versions. It is necessary to identify the runtime and certificate libraries used by each affected process, including those provided within containers. After applying the recommended updates, it is essential to confirm that the updated services are running and that the required connections are still functioning properly. Disabling certificate checks to restore failed connections will remove the protection that these checks are intended to provide.