はじめに：なぜフロントエンドエンジニアも知るべきか？

近年、Web3や分散型アプリケーション（dApps）の開発において、JavaScriptやTypeScriptはフロントエンドのみならず、バックエンドやP2Pネットワーク層でも広く利用されています。今回解説する脆弱性は、IPFS（InterPlanetary File System）やlibp2pなどの分散型技術スタックの根幹をなすJavaScriptライブラリ `@libp2p/kad-dht` に関連するものです。直接的にUIを扱うわけではないかもしれませんが、HeliaのようなモダンなIPFSクライアントをJavaScriptで利用している、あるいは将来的に分散型ストレージを扱う可能性があるフロントエンドエンジニアにとって、この深刻な脆弱性は決して他人事ではありません。自身のプロジェクトが知らぬ間に攻撃対象となるリスクを理解し、適切な対策を講じることが重要です。

脆弱性の概要と深刻度：認証なしでサービス停止

今回報告された脆弱性は、GHSA-32mq-hpph-xfvr（CVE-2026-45783）として識別され、深刻度は「High」と評価されています。この脆弱性を悪用すると、認証されていない攻撃者が、特定の不正なメッセージを繰り返し送信するだけで、`@libp2p/kad-dht`をサーバーモードで実行しているノードのディスク容量を無制限に使い果たし、最終的にサービスを停止させることが可能になります。特筆すべきは、特別な認証が一切不要である点です。つまり、インターネット上に公開されているすべての対象ノードが、このリスクに晒されていることになります。緊急の対応が強く推奨されます。

技術的詳細：なぜディスクが枯渇するのか？

この脆弱性は、主に以下の2つの技術的な欠陥が組み合わさることで発生します。

通常、DHT（分散ハッシュテーブル）に保存されるデータは、そのキー形式（例: `/pk/<multihash>`) に基づいて内容が検証されます。これは不正なデータが保存されるのを防ぐための重要なセキュリティ機能です。しかし、この脆弱性では、スラッシュ（`/`）で区切られた部分が3つ未満という不正な形式のキーを持つデータが送られてきた場合、本来行われるべき検証処理が**サイレントにスキップ**されてしまいます。結果として、ノードは検証されなかった不正なデータをエラーを出すことなく、そのまま自身のデータストアに保存してしまうのです。これは、セキュリティチェックが意図せず機能しなくなる致命的なバグと言えます。

DHTノードのRPC（リモートプロシージャコール）メッセージ処理ループには、受信するメッセージ数やデータ量に対する明確な制限が設けられていません。さらに、各メッセージを受信するたびにアイドルタイムアウトがリセットされる設計になっています。このため、攻撃者はタイムアウトに引っかかることなく、理論上、**無制限に大量のメッセージ**を送り続けることが可能になります。この特性と前述の検証バイパスが組み合わさることで、攻撃者は際限なく不正なデータをノードに送りつけられる状況が生まれます。

上記2つの欠陥が重なることで、攻撃者は認証なしで、1メッセージあたり最大4MBの不正なデータを、同時に最大32のストリームを通じて、無制限に送り続けることができます。これにより、ターゲットとなるノードのデータストアは、ホストの物理的なディスク容量いっぱいまで不正なデータで埋め尽くされてしまいます。ディスクが満杯になると、ノードは新しいDHTレコード、ピア情報、またはその他のアプリケーションデータを一切書き込めなくなり、完全に利用不能な状態（サービス拒否: DoS）に陥ります。これは、システムの可用性を直接的に破壊する、非常に深刻な事態です。

影響を受ける環境と確認方法

この脆弱性の影響を受けるのは、`@libp2p/kad-dht`を**サーバーモード**（`clientMode: false`がデフォルト設定）で実行しているすべてのノードです。これには、以下のアプリケーションや環境が含まれます。

重要な点として、クライアントモード（`clientMode: true`）で動作しているノードは影響を受けません。ご自身のプロジェクトでIPFSやlibp2p関連のライブラリを利用しており、特にJavaScript/TypeScriptでDHTノードを運用している場合は、`@libp2p/kad-dht`がサーバーモードで動作していないか、早急に確認してください。HeliaのようなモダンなIPFSクライアントをWebブラウザやNode.js環境で利用している場合も、その内部実装や設定によっては影響を受ける可能性があります。

推奨される対応策と今後の展望

この脆弱性に対する最も効果的な対応策は、根本原因である`verifyRecord`関数において、不正なキー形式のレコードをサイレントに保存するのではなく、明示的にエラーをスローして拒否するように修正することです。これにより、少なくとも検証をバイパスして不正なデータを保存されることを防ぐことができます。

分散型システムは従来のクライアント-サーバーモデルとは異なるセキュリティ課題を抱えています。特にP2Pネットワークの基盤となるライブラリの脆弱性は、広範囲に影響を及ぼす可能性があります。Web3エコシステムに携わるフロントエンドエンジニアも、このような低レイヤーのセキュリティ情報に常にアンテナを張り、自身の開発するアプリケーションの安全性を確保するための知識を深めていくことが求められます。