Skip to content
速報Dev Stack

Radicle 1.10.3以前、非公開リポジトリを平文で送信

Radicle(ラディクル)の1.10.3までの全リリースがリポジトリのデータを暗号化せずに送り、攻撃者が信頼済みピアになりすませる。修正版はまだなく、Radicle 2.0でネットワークが変わる。

著者 Tech AI Wire Team

3 分で読めます

紫色のイラストのバナーの下に、2026年9月23日付でネットワークプロトコルの脆弱性を公表するRadicleの開示ページが表示されている。

数字で見る

latest vulnerable release, per the reporter
1.10.3
critical flaws disclosed
2
fixed releases available so far
0

Gitリポジトリを共有するピアツーピアのネットワークであるRadicleは、2026年9月23日、公開済みのすべてのバージョンがネットワーク通信を暗号化せずに送っていると明らかにした。2つ目の欠陥では、攻撃者が信頼されたピアを装える。この2つが重なると、Radicleで同期した非公開リポジトリは、通信経路上の誰にでも読まれたり、持ち出されたりしうる。修正版はまだ存在しない。

Radicleプロジェクトの開示文は、ネットワーク上での非公開リポジトリの利用を直ちにやめるよう利用者に求めている。すでに取得した非公開データは漏えいしたものとして扱うようにとも述べている。

2つの欠陥

Radicleのノードは、GitHubのような中央サーバーを介さず、互いに直接通信する。各接続は、暗号化された通信路を作るための定評ある手順であるNoiseに基づくハンドシェイクで始まる。ハンドシェイクは双方の身元を証明し、その後のすべてを暗号化するためのものだ。

Radicleによれば、そのどちらも意図通りに動いていない。

欠陥何が起きるか報告
平文での通信ハンドシェイク後のデータが暗号化されずに送られる2026年6月24日、Konstantinos Maninakis氏
ピア認証の不備攻撃者が許可リストにあるピアを装える2026年8月12日、cryptocode氏

許可リストは、非公開リポジトリを指定したピアだけに限るRadicleの仕組みである。2つ目の欠陥はこれを無効にする。Radicleの投稿はリスクを率直に書いている。「現実的な脅威は、あなたのノードと同期先のノードの間の経路にいる誰かであり、どんな設定も許可リストもそれを防げない」。

バグの所在

1つ目の欠陥を見つけたManinakis氏は、同じ日に技術的な解説を公開した。原因はProtocol::writeというメソッドの論理の誤りだという。よく使われるプロキシの方式であるSOCKS5向けに書かれた条件が、Noiseの通信にも流用されていた。その結果、ハンドシェイク後に暗号化が有効にならなかった。

同氏はデータがどれほど丸見えかを示している。本番のシードノードへの実際の接続では、ハンドシェイク後の最初のバイトが「rad」の「r」の文字だった。「2つのノード間のネットワーク経路にいる誰もが…そのすべてを読める」と同氏は書く。

欠陥はRadicleだけでなく、共有ライブラリにもある。netservices.rsリポジトリで未解決のissueは、ハンドシェイクが終わるとNoiseSessionのコードが書き込みを内側の接続にそのまま渡すと指摘する。issueは「接続を観測できる者はアプリケーションのデータを読める」と述べる。ストリームを改ざんできる者は認証を完全に回避できるとも警告している。

修正はいつか

まだである。Radicleは、修正にはパッチではなくメジャーバージョンの引き上げが必要だとしている。

2つの情報源は置き換え先を少し違う形で説明している。Radicleの投稿は、独自のNoise構成をirohというピアツーピアの仕組みに置き換えるとしている。Maninakis氏は、未公開のRadicle 2.0がQUICと、Rustの暗号ライブラリであるrustlsによるTLSを使うと書く。どちらも、この変更で1.xのネットワークとの互換性がなくなる点では一致している。つまり新旧のノードは互いに通信できない。

Maninakis氏は1.10.3までのすべてのリリースが影響を受けるとしている。Radicleは公開済みのすべてのバージョンが影響を受けるとしている。どちらの情報源もCVE番号を示していない。

開発者にとっての意味

Radicleで非公開リポジトリを扱っているなら、今すぐネットワーク経由の同期をやめよう。Radicleの投稿は、リポジトリIDを使ってrad block <RID>でシードを止める方法を示している。

すでに同期したものは見られたと考えよう。そうしたリポジトリにAPIキー、トークン、パスワードなどの秘密情報がないか確認し、あれば交換する。Radicleの助言は、取得済みの非公開データを漏えいしたものとして扱うことであり、Gitの履歴に残ったキーもそれに含まれる。

どうしても同期を続けるなら、自分で管理する層で通信を包もう。Radicleは緩和策としてVPN、WireGuard、SSHトンネルを挙げている。これらはプロトコルに欠けている暗号化を補う。

公開リポジトリはもともと秘密ではないため、平文の欠陥の影響は小さい。それでも、なりすましの欠陥は追っておく価値がある。ノードが誰と通信していると信じるかを揺るがすからだ。

2.0への移行を計画しておこう。互換性がなくなるため、頼りにしているすべてのノードがほぼ同時に移行する必要がある。自分のプロジェクトでnetservices.rsライブラリを使っているなら、同じバグが影響しうるのでissue #48を追っておこう。

出典

  1. Disclosure of Vulnerability in the Network Protocol - Radicle
  2. Radicle cleartext transport vulnerability - maninak.com
  3. NoiseSession does not encrypt application data after the handshake (issue #48) - GitHub

関連記事