ニュース暗号資産eMudhraの証明書欠陥を受け、イーサリアムクライアントTekuとBesuが緊急修正をリリース

eMudhraの証明書欠陥を受け、イーサリアムクライアントTekuとBesuが緊急修正をリリース

著者: CryptoMeter io·

重要ポイント

  • •2025年4月の暗号処理エラーにより、eMudhraは秘密鍵が復元可能な8つの中間認証局鍵を生成した。この弱点は約18カ月間検出されず、2026年10月17日に独立系研究者が発見した。
  • •Tekuは10月27日にバージョン26.10.3を、Besuは10月26日にバージョン26.10.2をリリースし、Dockerディストリビューションから影響を受けた認証局への信頼を削除した。
  • •特定の設定下では、中間者攻撃者がバリデーターと外部署名サービス間の通信を操作し、理論上ブロック手数料報酬を攻撃者の管理するアドレスへ誘導できる可能性があった。
  • •デフォルトのイーサリアムメインネット設定には影響がなく、開発者は露出したTekuインストール環境での悪用は確認されていないと報告している。
  • •サーバー上でTekuやBesuを直接実行する管理者は、Javaのインストール環境と証明書トラストストアを個別に確認する必要がある。イーサリアムクライアントの更新だけでは脆弱性は解消されない可能性がある。
eMudhraの証明書欠陥を受け、イーサリアムクライアントTekuとBesuが緊急修正をリリース

イーサリアムクライアント開発者は、インドの認証局eMudhraにおける暗号処理の失敗により一部のノード設定が潜在的な攻撃にさらされたことを受け、TekuとBesu向けの緊急セキュリティアップデートをリリースした。この欠陥により、攻撃者が信頼された証明書を偽造し、イーサリアムインフラのコンポーネント間の通信を傍受することが可能になった可能性があるが、開発者はデフォルトのイーサリアムメインネット設定には影響がないことを確認した。

ブロックチェーンの運用とバリデーターインフラを支える両クライアントには、緊急パッチが適用された。Tekuはコンセンサスレイヤーのクライアント、Besuは実行レイヤーのクライアントであり、いずれもJavaで記述されている。この点が、修正がさまざまな運用環境にどのように届くかを左右する。研究者は潜在的に深刻な攻撃シナリオを特定したが、開発者は影響を受けたTekuインストール環境での悪用は確認されていないと報告している。

eMudhraの証明書失敗がセキュリティリスクを生んだ経緯

今回のインシデントは、2025年4月のeMudhraの証明書生成プロセスにおける暗号処理のエラーにさかのぼる。同社は、暗号強度が不十分な8つの中間認証局鍵を生成し、秘密鍵が復元可能な状態になっていた。

認証局はHTTPSの信頼モデルの要であり、アプリケーションはその署名に基づいて、接続先サーバーが正当であることを確認する。2026年10月17日、独立系の研究者がこの脆弱性を発見した。これにより、攻撃者は偽の証明書を作成し、脆弱なアプリケーションに正当なものと誤認させる可能性があった。この問題は、独立したセキュリティ監査にもかかわらず、約18カ月間検出されないままだった。

eMudhraはその後、影響を受けた証明書を失効させ、スクリプトのエラーによって脆弱な暗号鍵が生成されたことを認めた。ロイターが報じたところによると、この一件により同社はグローバルなウェブサイトセキュリティ証明書事業から撤退したが、eMudhraは自社インフラと顧客データは侵害されていないと主張している。

TekuとBesuが緊急セキュリティアップデートを提供

これを受けて、イーサリアムクライアント開発者は、Dockerディストリビューションから影響を受けた認証局への信頼を削除した。Tekuは10月27日にバージョン26.10.3を、Besuは10月26日にバージョン26.10.2をリリースした。

これらのパッチは、侵害された証明書チェーンに依存するHTTPS接続に関連するリスクに対処するものだ。特定の設定下では、中間者攻撃(2者間のトラフィックを密かに中継・改ざんする攻撃)を行う攻撃者が、バリデーターと外部署名サービス間の通信を操作できる可能性があった。理論上、そのような攻撃により、ブロック手数料報酬が攻撃者の管理するアドレスに誘導される可能性もあった。

ただし、このシナリオを悪用するには、脆弱な設定や関連するネットワークトラフィックを傍受できる能力など、特別な条件が必要となる。影響を受けるHTTPS接続を持たないデフォルトのイーサリアムメインネットノードは、特定された露出の対象外だった。

イーサリアム運用者に追加のJava確認を求める

更新済みのDockerイメージを運用しているオペレーターは、イメージにランタイム環境が同梱されているため、コンテナを通じて証明書信頼の変更を受け取る。一方、サーバー上でTekuやBesuを直接実行している管理者は、Javaのインストール環境と証明書トラストストアを個別に確認する必要がある。基盤となるJava環境が影響を受けた証明書を信頼し続ける場合、イーサリアムクライアントだけを更新しても脆弱性は解消されない可能性がある。

今回の一件は、外部セキュリティインフラの弱点が、ブロックチェーンプロトコル自体を侵害することなくブロックチェーンアプリケーションにリスクをもたらしうることを浮き彫りにした。イーサリアムのバリデーターにとって、クライアントソフトウェアと証明書設定の安全性を維持することは、運用インフラと報酬を守るうえで依然として不可欠である。