はじめに：分散型ネットワークにおけるlibp2pの役割

日本のフロントエンドエンジニアの皆さん、こんにちは。最近ではWeb3やDApps開発において、ブラウザとP2P（ピアツーピア）ネットワークを繋ぐ技術が注目されています。その中で、多くの分散型システムで基盤として利用されているのがlibp2pです。

libp2pは、P2Pアプリケーションを構築するためのモジュール化されたネットワークスタックを提供し、ピアの発見、ルーティング、データ転送など、P2P通信に必要な複雑な要素を抽象化します。IPFS、Filecoin、Heliumなど、多くの主要なWeb3プロジェクトで採用されており、フロントエンドから直接P2P通信を行うためのライブラリも提供されています。

本記事では、libp2pの中核コンポーネントである`@libp2p/peer-store`に発見された高深刻度（High Severity）の脆弱性「GHSA-vrf4-mx87-p53w（CVE-2026-86039）」について、その詳細、影響、そして対策を技術的に掘り下げて解説します。

脆弱性の概要：PeerRecordの偽装とは？

この脆弱性は、`@libp2p/peer-store`が、PeerRecordという重要なデータ構造を処理する際に発生します。`PeerRecord`とは、特定のPeer IDが所有するマルチアドレス（通信可能なアドレス情報）などを、そのピアの秘密鍵で署名して「認証済み」とするためのデータです。

問題は、`consumePeerRecord`という関数にありました。この関数は、受け取った`PeerRecord`の署名（エンベロープ）が有効であることは検証しますが、**そのエンベロープを署名したピアのIDと、`PeerRecord`のペイロード内部で「このレコードは私のものだ」と主張しているピアのIDが一致するかどうか**を検証していませんでした。

具体的には、攻撃者は以下の手順でこの脆弱性を悪用できます。

1. 攻撃者は自分の秘密鍵で`PeerRecord`のエンベロープに署名します。

2. しかし、その`PeerRecord`のペイロード（内容）には、**被害者（ターゲット）のPeer ID**と、**攻撃者が制御するマルチアドレス**を記載します。

3. `consumePeerRecord`関数は、エンベロープの署名が攻撃者のものなので「有効」と判断し、かつペイロードに書かれた被害者のPeer IDを信じて、攻撃者のアドレスを「被害者の認証済みアドレス」として保存してしまいます。

技術的詳細：欠けていた検証ロジック

脆弱なコードは`packages/peer-store/src/index.ts`内に存在します。`RecordEnvelope.openAndCertify`はエンベロープ署名を検証しますが、その後の処理で、エンベロープ署名者から導出されたピアIDと、`PeerRecord`自体が主張するピアIDの比較が省略されていました。

本来であれば、以下の不変条件（invariant）が確認されるべきでした。

<code>peerRecord.peerId.equals(peerIdFromCID(envelope.publicKey.toCID()))</code>

libp2pの他の箇所、例えば`packages/protocol-identify/src/utils.ts`では、既にこのチェックが実装されており、今回の脆弱性がない安全な実装の参考となります。

この脆弱性は、GossipsubのPeer Exchange (PX) パスなど、ピアストアが署名済みPeerRecordを消費するあらゆる場所で悪用される可能性があります。

攻撃の影響：通信の妨害とアドレス帳汚染

この脆弱性が悪用されると、以下のような影響が発生します。

1. **認証済みアドレスの汚染:** ピアストアに保存された被害者の認証済みアドレスが、攻撃者によって制御されるアドレスに上書きされてしまいます。認証済みアドレスは、通常、接続確立の際に優先的に利用されるため、これが大きな問題となります。

2. **接続障害:** 被害者に接続しようとする他のピアは、偽装された攻撃者のアドレスを信じて接続を試みます。これにより、無効なアドレスへの接続試行が繰り返されたり、意図しない悪意のあるエンドポイントへ誘導されたりする可能性があります。結果として、正当なピアへの接続ができなくなり、サービス妨害（DoS）に繋がり得ます。

3. **ルーティング操作の可能性:** 分散型ネットワークにおけるピアの発見やルーティングの正確性が損なわれることで、ネットワーク全体の健全性や信頼性が低下する恐れがあります。

ただし、この脆弱性自体は、攻撃者が被害者のPeer IDを完全に乗っ取って、そのピアになりすまして通信を継続できるものではありません。接続確立フェーズでは、最終的に鍵の検証が行われるため、攻撃者が被害者の秘密鍵を持たない限り、暗号化された安全な接続を確立することはできません。影響は主にアドレスの誤認識と接続の妨害に限定されます。

対策と緩和策

この脆弱性に対する最も効果的な対策は、libp2pライブラリを最新の修正済みバージョンにアップグレードすることです。具体的な修正バージョンについては、公式のアナウンスやGitHubのリリースノートを確認してください。

ご自身のプロジェクトで`@libp2p/peer-store`を使用している場合、またはlibp2pを依存関係に持つ他のライブラリを使用している場合は、早急に依存関係を更新し、潜在的なリスクを排除してください。特に、Web3プロジェクトやブラウザベースのDAppsなど、ユーザーのP2P通信の健全性が直接影響するアプリケーションでは、この対応が不可欠です。

今後も、P2Pネットワークのセキュリティにおいては、ピアの認証とデータの信頼性検証が極めて重要であることを再認識し、常に最新のセキュリティプラクティスに従うようにしましょう。

まとめ

libp2pの`@libp2p/peer-store`における認証済みアドレス偽装の脆弱性は、分散型アプリケーションのネットワーク接続に深刻な影響を及ぼす可能性があります。フロントエンドエンジニアの皆さんには、使用しているライブラリのバージョンを確認し、速やかにアップデートを適用することをお勧めします。

P2Pネットワークの安全性は、その基盤となるライブラリのセキュリティに直接依存します。常に最新の情報をキャッチアップし、安全な開発を心がけましょう。