EthereumクライアントがETH報酬を転送する可能性のある脆弱性をパッチ適用
2026年10月下旬、EthereumのコンセンサスクライアントTekuと実行クライアントBesuが、インドの企業eMudhraから漏洩した証明書認証局キーに関連する脆弱性を修正するセキュリティリリースを公開しました。この欠陥により、特定のHTTPS接続を傍受した攻撃者がバリデータが使用する外部サービスを偽装し、ブロック報酬を転送したり、機密性の高い署名を取得することが可能でした。研究者たちは、eMudhraの8つの中間証明書認証局の秘密鍵が十分なランダム性で生成されておらず、それらの鍵が公開証明書自体から復元可能であることを発見しました。両クライアントで使用されるJavaランタイムはデフォルトで証明書の失効チェックを行わないため、ブラウザや主要なオペレーティングシステムがブロックした後も、一部のDockerイメージやインストールでは影響を受けた証明書チェーンを信頼し続けていました。HTTPSエンドポイントを避けるよう設定されたデフォルトのメインネットTeku構成は影響を受けず、開発者は確認された悪用は報告されていないと述べています。
パッチにより、更新されたDockerイメージから関与したルートに対する信頼が削除されます。一方、スタンドアロンバイナリを実行しているオペレーターは、ローカルのJava信頼ストアを別途対応する必要があります。この出来事は、コアプロトコルが安全であっても、外部インフラストラクチャの依存関係がステーキング操作に狭範囲だが高影響のリスクをもたらす可能性があることを浮き彫りにしています。TekuとBesuによる迅速な対応は、Ethereumのクライアントの多様性と積極的なセキュリティ対策が、オペレーターが利用可能な更新を適用し、外部接続設定を見直すことで、証明書関連の脅威をバリデーターリワードに広範囲に影響を与える前に抑えることができることを示しています。
研究者は2026年10月17日、eMudhraの8つの中間証明機関のプライベートキーが、十分なエントロピー不足で生成されたことを特定した。これらのキーは、2025年4月のキー生成セレモニー以来存在していた状態であり、公開証明書から効果的に復元可能であった。8つの中間機関のうち6つはTLS接続をサポートし、残り2つはコード署名に関連していた。プライベート情報が公開された後、攻撃者は、影響を受けた機関を信頼し続けるソフトウェアが有効と認識する偽の証明書を発行できるようになった。eMudhraは2026年10月18日にこれらの中間機関を無効化した。主要なプラットフォームは迅速に対応し、ブラウザとオペレーティングシステムは2026年10月17日から20日にかけてこれらの証明書のブロックを開始し、マイクロソフトは2026年10月26日から27日にかけてWindowsおよびEdgeの更新を発表し、信頼リストから関連するルートを削除した。この暗号学的失敗自体はEthereumプロトコルの問題ではなかったが、TekuおよびBesuはノードが行うすべてのHTTPS接続にJavaの証明書検証に依存しているため、影響を及ぼした。Javaのデフォルト動作では取消チェックをスキップするため、ブラウザ環境よりも特定のインストールが長期間露出した。この出来事は、単一の証明機関の運用ミスが標準的なTLS信頼ストアに依存する専門的なインフラにどのように拡散するかを示している。
鍵の復元には高度な暗号解析は必要なく、公開証明書を確認すれば、不十分なランダム性により導出が容易だった。マイクロソフトの10月26日の警告では、これらの鍵を使用して信頼できる機関から発行されたかのように見せかける証明書を作成でき、ウェブサイトやサービスのなりすましが可能になる可能性があることが確認された。Ethereumオペレーターにとって、実質的な影響は、HTTPSエンドポイント、リモートビーコンノード、外部署名者、ブロックビルダー、またはリレーに依存するすべてのバリデータ設定が、基盤となるJavaランタイムが compromis されたチェーンを依然として信頼している場合、偽造された証明書を受け入れてしまうことであった。Ethereumクライアントで使用されるピアツーピアネットワーキングは、これらの証明機関に依存しないため、影響を受けなかった。復元可能な鍵と取消されないJava検証の組み合わせにより、ネットワークパス上に位置する中間者攻撃者がクライアントソフトウェアに信頼できるアイデンティティを提示できる期間が生じた。クライアントチームは、基盤となるJavaの更新を待つのではなく、Dockerイメージから関連するルートを削除することで対応し、最新のイメージを取得するオペレーターが強化されたトラストストアを受け取れるようにした。この階層的対応—CAでの取消、プラットフォームでのブロック、およびクライアント固有のイメージ更新—は、ほとんどのステーキング設定における実質的な攻撃面を制限した。
Tekuのセキュリティアドバイザリーは、攻撃者がクライアントによって受け入れられる偽造された証明書を提示できるようになると、具体的な攻撃経路が可能になることを示しました。一つのシナリオは、バリデータが調整に使用するリモートビーコンノードを装うことです。接続が傍受され、偽造された証明書が受け入れられた場合、バリデータは提案しようとしているブロックに関する操作された情報を受信する可能性があります。その場合、クライアントは、手数料受取アドレスがオペレーターの指定アドレスではなく、攻撃者が制御する口座を指すブロックを構築し署名する可能性があります。そのブロックに含まれるトランザクション手数料および優先手数料はすべて攻撃者に流れます。アドバイザリーはまた、バリデータキーを別途保管し、要求に応じて署名を返す外部署名サービスについても示しました。このような署名者を装える攻撃者は、報酬の送付先に影響を与える変更を含む、重要な操作に使用される署名を取得できます。Tekuは、外部署名者ケースをより深刻な設定の一つとして位置づけましたが、一部の設定では相互TLS認証により、署名の compromis ではなくサービス拒否に影響が制限されます。
追加で公開された接続タイプには、実行クライアント、ブロックビルダー、リレー、およびバリデーター設定データを提供するサービスが含まれます。いずれの場合も、核心的なリスクは同じです：クライアントソフトウェアが偽造された証明書を正当なものとみなすため、提案されたブロックの内容やキーの処理を変更するデータまたは指示を受け入れてしまいます。この脆弱性は、通常の運用下ではバリデーターの署名キーへの直接的なアクセスを許可しません。代わりに、バリデーターが参照する外部サービスの整合性を損ないます。Ethereumのブロック報酬と手数料は、提案されたブロックに埋め込まれたアドレスに応じて支払われるため、提案段階での成功した操作により、すでに獲得した資金を移動することなく価値を転送することが可能です。これらの経路の悪用は報告されておらず、設定にHTTPS URLを含まないデフォルトのメインネットTekuインストールは影響を受けないセットに含まれます。ただし、詳細なシナリオは、基礎となるプロトコルやピアツーピア層が変更されていないにもかかわらず、クライアントチームがこの問題を即時のDockerイメージ更新を必要とするものとみなした理由を明確に示しています。
Tekuは2026年10月27日にバージョン26.10.3をリリースし、eMudhra関連のリスクに対応しました。リリースノートによると、DockerイメージはもはやemSign ECC Root CA – G3、emSign Root CA – G1、emSign Root CA – G2、およびAAA Certificate Servicesのルートを信頼しません。これらのルートは、中間認証機関が侵害された後、OpenJDKによって削除されていましたが、Tekuが使用するEclipse Temurinベースイメージには、クライアントリリース時点ではまだ該当する修正が反映されていませんでした。更新されたイメージを提供することで、Tekuチームは新しいタグをプルするオペレーターが、侵害されたコンテンツを信頼ストアから除外したJavaランタイムを受け取ることを保証しました。このリリースに付随する警告では、HTTPS URLを一切設定していないデフォルトのメインネットノードには対応が必要ないと強調されています。リスクは、ビーコン調整、外部署名、ビルダー、または同様のサービスのために意図的にリモートHTTPSエンドポイントに接続する構成に限定されます。
26.10.2までタグ付けされた古いDockerイメージを実行しているオペレーターは、影響を受けるルートを信頼するランタイムを引き続き使用しています。ホストのJavaインストールを更新しても、既存のコンテナ内のランタイムは自動的に更新されないため、新しいイメージをプルする必要があります。Tekuはさらに、Java 26はライフサイクルが終了しており、パッチ適用済みのビルドは提供されないことを指摘し、このバージョンを使用し続けているオペレーターには、現在の長期サポートリリースであるJava 25への移行と、対応する-jdk25イメージタグの使用を推奨しています。このリリースは、信頼ストアからの証明書ルートの削除とランタイムバージョン管理に関するガイドラインを組み合わせたものです。この変更はDockerイメージの信頼ストアに限定されているため、コンセンサス動作やバリデーターキーの処理には影響しません。本更新は緊急のコンセンサスアップグレードではなく、影響を受ける構成の範囲が限定的であることを反映して、推奨されるセキュリティ対策として提示されています。
同じエコシステムが保守する実行層クライアントであるBesuは、2026年10月26日にバージョン26.10.2をリリースし、Dockerイメージに同じルート削除を実装しました。並行したタイミングと同一の証明書ターゲットは、JavaベースのEthereumクライアントスタック全体でeMudhra事件に対する協調的な認識があったことを示しています。実行クライアントは、コンセンサスクライアントや外部サービスと連携してペイロード構築やトランザクション含ませを行いますが、それらが維持するすべてのHTTPS通信パスは、Tekuに影響を与えるのと同じ証明書検証ルールの対象となります。Besuは、改ざんされた認証機関への信頼をイメージから削除することで、Docker配布版を利用している運用者に対する対応する攻撃面を閉じました。
Tekuと同様に、Besuの更新は、別途管理されたJavaランタイムを使用するスタンドアロンバイナリインストールを自動的に修正しません。そのカテゴリの運用者は、ローカルのトラストストアまたはJavaバージョンを個別に確認して更新する必要があります。両クライアントの同時リリースは、Ethereumノードソフトウェアスタックのコンセンサス側と実行側が、Java証明書処理への共通依存関係を認識していたことを示しています。多くの本番バリデーターがTekuのようなコンセンサスクライアントとBesuのような実行クライアントの両方を実行しているため、同時更新により、ノードペアのどちらか側に脆弱なルートに対する残存の信頼が残る可能性を低減します。リリース前に悪用が報告されていないことから、実質的な対応期間は限定的であったと考えられますが、協調的なパッチはEthereumプロトコル自体の外で発生した既知の暗号学的障害に対する慎重な対策を表しています。
重要な技術的詳細として、Javaの証明書検証はデフォルトで失効状態をチェックしません。eMudhraが中間証明書を失効させ、主要なプラットフォームがそれらをブロックした後でも、信頼ストアに該当するルートまたは中間証明書を含み続けるJavaランタイムは、それらの認証機関にチェーンされる証明書を引き続き受け入れ続けました。OpenJDKは、まず侵害された中間証明書をブロックし、その後関連するルート4つを削除する修正をリリースしました。しかし、古いTemurinまたはOpenJDKビルドを含むDockerイメージは、これらの修正を自動的に受信しませんでした。プラットフォームレベルの失効と組み込みJavaランタイムの動作とのこのギャップが、クライアント固有のイメージ更新を必要としました。
Ethereumオペレーターにとって、この影響は理論的なものではなく、運用上のものです。リモートサービスのHTTPSエンドポイントを設定に含むバリデーターは、使用するJavaランタイムの信頼判断を継承します。そのランタイムが更新されていない、またはパッチ適用済みのイメージに置き換えられていない場合、クライアントは偽造された証明書を受け入れ続けます。相互TLSや証明書のピン留めは、丁寧に設計された環境でリスクを軽減できますが、多くの本番環境では標準的なトラストストア検証に依存しています。したがって、TekuとBesuのリリースは、コンテナ化されたノードソフトウェアがホストシステムとは独立した証明書ストアを備えているという実用的な注意喚起です。Dockerイメージを不透明なブラックボックスとして扱うオペレーターは、外部のインシデントがアップデートを強いるまでこの詳細を見落とす可能性があります。この出来事は、JavaベースのEthereumクライアントを実行する際に、アップストリームのJavaセキュリティアドバイザリーを監視することの価値も浮き彫りにしています。
Tekuのアドバイザリーは、設定にHTTPS URLを含まないデフォルトのメインネットノードは影響を受けず、任何の対応も必要ないと明確に述べています。リモート署名やリモートビーコンエンドポイントを使用せず、ローカルにコンセンサスクライアントと実行クライアントを共同配置しているほとんどのバリデーターはこのカテゴリに該当します。Ethereumが使用するピアツーピアの発見およびゴシッププロトコルは、eMudhra証明書認証局に依存していませんため、標準的な設定はさらに保護されています。リスクは、運用の利便性、署名キーの地理的分散、またはサードパーティのブロック構築サービスとの統合のために意図的に外部HTTPS依存関係を導入したオペレーターに集中しています。この区別は、ネットワーク全体への影響を評価する上で重要です。メインネットバリデーターの大多数は、脆弱な証明書チェーンに一切アクセスしない設定で動作しているため、パッチが適用される前から理論的な攻撃面は限定的でした。
一方で、クライアントチームが更新されたイメージをリリースすることを決定したことで、リモートサービスを利用しているオペレーターのサブセットが保護され、今後のイメージ取得が強化されたベースラインから開始されることが保証されます。HTTPSを介して初期状態をダウンロードするテストネット構成は、潜在的に暴露されている可能性があるとして警告されました。これは、メインネット外でも同じ証明書のロジックが適用されることを示しています。HTTPSによるブートストラップまたはリモートエンドポイントに依存するすべてのネットワークのオペレーターは、2026年10月リリースを自環境において必須とみなすべきです。デフォルト構成と非デフォルト構成の明確な分離により、アドバイザリーはバリデーターセットの大部分に対して正確かつ安心できる内容となりました。
Tekuが列挙したシナリオの中で、外部署名サービスはより高い深刻度を有していました。これらのサービスは、バリデーターの秘密鍵をオフラインまたは専用ハードウェアに保管し、ネットワーク接続を通じて署名リクエストに応答します。攻撃者が偽造された証明書を提示して署名者を装った場合、バリデータークライアントはオペレーターが意図しなかった操作（手数料受取人設定の変更や脱退の開始など）を許可する署名を受け入れる可能性があります。相互TLS認証を強制する構成では、攻撃者が認証ハンドシェイクを完了できないため、影響はサービス拒否に限定されます。相互認証が存在しない場合、使用可能な署名を取得するリスクはより高くなります。リモートビーコンノードは関連するが異なる懸念を呈しています。
リモートビーコンエンドポイントに調整業務の一部を委任するバリデータは、そのエンドポイントから義務、ブロック内容、ネットワーク状態に関する情報を信頼します。したがって、成功したなりすましは、ブロックに埋め込まれた手数料受取アドレスを含む、バリデータが最終的に提案するブロックに影響を与える可能性があります。ブロックビルダーとリレーは、操作されたペイロードが注入される可能性のある、さらに他のHTTPSインターフェースを導入します。いずれの場合も、攻撃者はまず傍受を可能にするネットワーク上の位置を確保し、次にパッチが適用されていないJavaランタイムが受け入れる証明書を提示する必要があります。これらの要件の組み合わせは、現実的な攻撃者の範囲を狭めますが、成功した提案による手数料の転送という潜在的な利益は、防御パッチの適用を正当化します。外部署名者またはリモートインフラを運用するオペレーターは、クライアントの更新とそれらのリンク上の認証メカニズムの見直しの両方を優先すべきです。
Dockerユーザーは、新しいTeku 26.10.3またはBesu 26.10.2のイメージをプルすることで対応できます。クライアントをスタンドアロンバイナリまたはパッケージとしてインストールする運用者は、ホストシステムに存在するJavaランタイムに依存します。これらのインストールでは、クライアントのリリース自体がホストのトラストストアを変更しません。したがって、運用者は、インストールしたJavaバージョンに、脆弱なルートを削除するOpenJDKの修正が含まれていることを確認するか、証明書ストアを手動で調整する必要があります。Tekuは特に、Java 26はエンドオブライフであり、パッチ適用済みのビルドが提供されないことを警告しており、継続的なサポートとセキュリティ更新のためにはJava 25への移行が必要です。このコンテナ化されたデプロイとベアメタルデプロイの違いはEthereumインフラでは一般的であり、ノード運用者にとって実用的なチェックリスト項目となっています。
Javaバージョンの確認、トラストストアの内容の確認、およびHTTPSエンドポイントが信頼されていないサービスを指していないことを検証することが、パッチ適用後の最低限のセキュリティ対策です。この根本的な暗号学的障害はEthereumの外部で発生したため、運営者が使用している他のすべてのJavaベースのツールにも同様のJava更新義務が適用されます。したがって、クライアントに関するアドバイザリーは、TekuおよびBesuに対する具体的な修正であると同時に、運営者の全体スタックにおける証明書処理の監査を促す広範な通知でもあります。ホストのJava環境を対応しない場合、クライアントソフトウェア自体を更新した後でも理論的な攻撃経路は開いたままになります。
Tekuのアドバイザリおよび同時期の報告では、この脆弱性の悪用は観測されていないと明記されています。攻撃が成功するためには、パッチが適用されていないJavaランタイム、外部サービスへのHTTPS接続、および偽造された証明書を提示しながらその特定の接続を傍受できる攻撃者が必要という限定的な条件が揃う必要があるため、既知の事例が存在しないことは一貫しています。ほとんどのバリデーターは、最初の2つの条件を同時に満たしていません。10月17日に回復可能な鍵が公開されてからクライアントイメージがリリースされるまでの期間が短かったことにより、実用的な攻撃の機会はさらに狭まりました。
観測された攻撃がなかったからといって、パッチの価値が低下するわけではありません。証明書に関連する脆弱性は、機会主義的な攻撃者が現れるまで眠ったままになる可能性があります。Dockerの信頼ストアから compromis されたルートを削除することで、クライアントチームは更新を行うオペレーターによる偽造証明書の受信を排除しました。この出来事は、外部の暗号的失敗がEthereumステーキングインフラとどのように交差するかをリアルタイムで示し、オペレーターに自身の依存関係グラフを見直すきっかけを与えました。今後、証明書認証機関や言語ランタイムに関連する事象が発生した場合も、同様のクライアントレベルの対応が取られる可能性が高く、迅速でターゲットを絞った対策のパターンが強化されます。
eMudhraの事象はEthereumに特有のものではなく、標準的なTLS信頼ストアに依存するあらゆるソフトウェアは、信頼する証明機関のセキュリティ姿勢を継承します。Java、Go、その他の言語ランタイムを組み込んだブロックチェーンクライアントは、コンセンサス変更に適用するのと同じくらい慎重に、アップストリームの証明書更新を追跡する必要があります。Javaのデフォルト設定が失効チェックを省略していたため、影響が拡大し、クライアントチームは独自の信頼ストアの修正をリリースせざるを得ませんでした。コンテナ内に長期間使用されるランタイムをパッケージ化する他のエコシステムも、同様のリスクに直面しています。
Ethereumステーキングコミュニティにとっての実践的な教訓は、運用セキュリティが鍵管理やクライアントバージョン管理を超えて、ネットワーク接続されたすべてのコンポーネントの証明書検証動作を含むということである。リモート署名、分散型ビーコンノード、またはサードパーティのリレーを導入するオペレーターは、監視が必要な追加の信頼境界を導入することになる。CAの取り消し、プラットフォームのブロック、クライアントイメージの更新を通じてこの特定の脆弱性が成功裏に封じ込められたことは、各層が迅速に対応すれば層別防御が機能することを示している。継続的なクライアントの多様性は依然として価値がある。異なる実装は、外部依存関係を異なる速度で検出または緩和する可能性があり、単一の証明書障害がバリデーターセット全体に同時に影響を与える可能性を低減するからである。
2026年10月の証明書パッチは、その他のバリデータ関連のセキュリティへの注目の中での配信となった。以前に公開されたステーキングサービスインフラや手数料受取先の取り扱いに関する情報は、既に大規模な自発的な退出と報酬フローの監視強化を促していた。別途、開発者は、即将到来のGlamsterdamアップグレードの草案ルールにおける入金ルーティングの問題を解決した。この問題は、特定の公開鍵の衝突時にステーキング入金が誤って割り当てられる可能性があったが、追加のレビューの後、コンセンサス仕様に修正が統合された。これらの同時発生した出来事は、コアプロトコルが進化し続ける中でも、バリデータの経済モデルと運用セキュリティが引き続き注目されていることを示している。
この証明書の欠陥はその発生源が異なり、Ethereumの仕様やクライアントの合意バグではなく、外部CAに起因していたが、同じ経済的側面、すなわちプロポーザーが獲得した手数料と報酬の受取先に影響を及ぼした。したがって、クライアントが迅速に対応したことは、報酬の不正な転送につながる現実的な経路をすべて高優先度で扱うというより広いパターンに合致している。多様なクライアント設定を維持し、オンチェーンで手数料受取アドレスを監視し、コンセンサスおよび実行ソフトウェアを最新状態に保つオペレーターは、このような外部ショックに対してより適切に対応できる。eMudhra事例における損失の発生がないことは、タイムリーなパッチ適用と設定管理が依然として有効な防御策であることを裏付けている。
バリデーターおよびノードオペレーターは、Dockerを使用する場合、Teku 26.10.3以降およびBesu 26.10.2以降を実行していることを確認してください。バイナリを使用する場合は、対応するパッチ適用済みJavaランタイムを使用してください。HTTPSエンドポイントの設定を確認し、必要に応じて相互TLSまたは証明書ピンニングを導入して追加の保護を実施してください。Java 26を使用しているオペレーターは、サポートされているリリースに移行する必要があります。信頼ストアの更新後も、予期しない手数料受取アドレスを持つブロックの監視は、低コストの検出方法として有効です。発見される前から、基盤となるキーが長期間回復可能であったため、過去の接続および証明書受諾ログを1回限りの監査することで追加の安心を得られます。ただし、これまでのところ悪用は報告されていません。
これらのステップは、ほとんどのオペレーターにとって変革的というより段階的なものです。メインネットのバリデーターの大多数は、脆弱な証明書チェーンに一切接触していないため、この事象をコンテナイメージやJavaランタイムを最新に保つための提醒として経験しています。外部サービスに依存しているユーザーにとっては、パッチが以前は十分に認識されていなかった特定の経路を閉じています。アップストリームの証明書およびランタイムに関するアドバイザリーへの注意を継続することで、今後同様の外部障害が類似の脆弱性を生む可能性を低減できます。TekuとBesuのチームによる協調行動は、即時の対応策を提供するとともに、Ethereumクライアントソフトウェアと交差する次回の外部暗号化インシデントに対処するためのモデルを提供しています。
eMudhraの証明書には具体的に何が問題でしたか？
2025年のキー儀式中に、eMudhraが運営する8つの中間証明機関の秘密鍵が不十分なランダム性で生成されました。これらの鍵は公開証明書から復元可能であり、取得した者は、ソフトウェアがこれらの機関を信頼し続けるような不正な証明書を発行できました。この中間機関のうち6つはTLSに、2つはコード署名に使用されていました。eMudhraは2026年10月17日にこの事実を発見後、これらの鍵を無効化し、主要なプラットフォームがその後関連するコンテンツをブロックしました。
この欠陥により、バリデーターは実際にETHの報酬を失ったのでしょうか？
確認された悪用や報酬の損失は報告されていません。クライアントアドバイザリおよび同時期の報道では、攻撃は観測されていないとされています。必要な条件の組み合わせ、パッチが適用されていないJavaランタイムと脆弱な外部サービスへのアクティブなHTTPS接続により、現実的な攻撃面は制限され、パッチ済みDockerイメージの迅速な提供によりさらなる暴露が低減されました。
デフォルトのEthereumメインネットノードは影響を受けますか？
HTTPS URLを含まないデフォルトのメインネットTeku設定は影響を受けず、任何の対応も必要ありません。同様の原則がBesuの設定にも適用されます。このリスクは、ビーコンノード、外部署名者、ビルダー、または同様のサービスに対して意図的にリモートHTTPSエンドポイントを設定したオペレーターに限定されます。
証明書が無効化された後も、Javaランタイムが脆弱なままだったのはなぜですか？
Javaはデフォルトで証明書の失効状態をチェックしません。中間証明書がブラウザやオペレーティングシステムによって失効・ブロックされた後も、信頼ストアに該当するルート証明書が含まれているJavaインストールは、それらにチェーンする証明書を引き続き受け入れていました。したがって、古いランタイムを同梱していたクライアントDockerイメージでは、明示的なルート証明書の削除が必要でした。
Dockerイメージを使用するオペレーターは何をすべきですか？
Tekuバージョン26.10.3以降およびBesuバージョン26.10.2以降をプルして実行してください。これらのイメージは、 compromisされたルートを信頼しなくなりました。ホストシステムを更新するだけでは、既存のコンテナ内のランタイムは更新されません。新しいイメージが必要です。
クライアントをスタンドアロンバイナリとして実行するオペレーターについてはどうですか？
これらのオペレーターは、ホストのJavaインストールを更新または再構成し、OpenJDKの修正を適用して影響を受けるルートを削除する必要があります。Java 26はエンドオブライフであり、パッチ適用済みビルドは提供されません。Java 25への移行を推奨します。クライアントソフトウェアの更新自体は、ホストのトラストストアを変更しません。
免責事項：本市場情報は、第三者、商業的、またはスポンサー提供の可能性のある情報であり、参考および教育目的での提供にとどまり、金融または投資アドバイス、勧誘、または保証を構成するものではありません。その正確性、完全性、信頼性および由此する損失について、当社は一切責任を負いません。投資および取引にはリスクが伴います。過去のパフォーマンスは将来の結果を保証しません。ユーザーは自ら調査し、慎重に判断し、すべての責任を負うものとします。詳細については、KuCoinの利用規約およびリスク開示をご確認ください。
免責事項: このページは、お客様の便宜のためにAI技術を使用して翻訳されています。最も正確な情報については、元の英語版を参照してください。