Ethereumの開発者たちは、バリデーターのデポジットとブロック報酬を危険にさらす可能性があった2件の別個の脆弱性を解消しました。1件は脆弱なウェブサイト証明書に関するもので、もう1件はネットワークの次期Glamsterdamアップグレードの草案ルールに埋め込まれていたものです。コンセンサスクライアントのTekuと実行クライアントのBesuが、それぞれこの問題に対処するパッチをリリースしました。Ethereumノードはコンセンサスクライアントと実行クライアントを並行して稼働させるため、ノードスタックの両レイヤーで同じ証明書のクリーンアップが必要となりました。

Tekuは10月27日にバージョン26.10.3をリリースし、その1日前の10月26日にはBesuがバージョン26.10.2をリリースしました。Tekuのリリースページによると、両リリースともEthereumノードの実行に使用されるDockerイメージから影響を受ける証明書 authority を削除しています。

脆弱な証明書鍵が指摘される

研究者たちは10月17日、インドのeMudhraが発行した8つの中間証明書が、公開情報から攻撃者が算出できる秘密鍵に依存していることを発見しました。これらの鍵があれば、攻撃者は偽のサービス向けの証明書を発行できた可能性があります。eMudhraは証明書を失効させましたが、Javaはデフォルトで証明書の失効を確認しないため、一部のJavaインストール環境では引き続き信頼されたままでした。TekuとBesuはいずれもJavaで書かれており、これが脆弱性がEthereumノード運用に波及した経緯です。

この発見は、Googleが秘密鍵を複数の環境に分割する暗号資産カストディ・セキュリティシステムを発表したのと同じ週の出来事でした。

バリデーター報酬が横取りされる可能性があった仕組み

この証明書の欠陥が問題となったのは、バリデーターが外部サービスへの接続に依存しているためです。こうした接続を傍受できる攻撃者は、接続先のサービスになりすますことが可能でした。Tekuは、リモートノードへの偽造接続により、ブロック手数料が攻撃者管理のアドレスに支払われる可能性があったと警告しました。影響を受ける構成では、外部署名サービスも追加のリスクとなり、攻撃者が報酬を迂回させる署名を取得する恐れがありました。

「メインネットのデフォルトのTekuノードは影響を受けず、対応は不要です」とTekuは述べています。クライアントチームは、既知の悪用事例はないと報告しています。

Glamsterdamのデポジット・ルールも修正

別の取り組みとして、研究者avsetsinがデポジット・ルーティングの誤りを特定したことを受け、開発者たちはGlamsterdam案のルールを改訂しました。また、10月26日に予定されていたHoodiテストネットのアップグレードも延期しました。

当初の草案では、ビルダーとバリデーターが同一の公開鍵を共有すると、ステーキング・デポジットがビルダーのアカウントに入る可能性がありました。Glamsterdamはブロック構築と検証を分離することを目的としており、改訂版の提案では保留中のデポジットを引き出し認証情報（withdrawal credentials）で仕分けし、バリデーターのデポジットとビルダーのデポジットを区別します。

クライアントチーム間で合意が得られなかったため、開発者たちは当初10月19日にこの修正を却下しましたが、その後テストを追加し、10月26日に改訂版ルールをマージしました。

ノード運営者に求められる対応はそれぞれ異なる

Glamsterdamの修正はEthereumの仕様には反映されましたが、ソフトウェアチームによる実装はまだ必要です。Glamsterdamは以前Sepoliaテストネットで稼働しており、Hoodiは新たな発動日を待っています。

Docker外でTekuやBesuを運用しているオペレーターは、Javaを個別に更新する必要があります。証明書のリスクは、バリデーターに支払われる優先手数料などEthereumのガス代から支払われる額に及ぶものであり、一般ユーザーのウォレット残高には影響しませんでした。Tekuは、サポート対象外のJava 26を使用しているユーザーにJava 25への移行を勧めています。

証明書のパッチは影響を受けるDockerイメージを解決するものであり、Glamsterdamの修正はEthereumのクライアントエコシステム全体での採用を待つ段階です。