Rucioで認証なしに管理者になりすませる脆弱性　修正版は7月に出ていた

GitHubは11月13日（日本時間）、科学データ管理のオープンソース「Rucio」の脆弱性「CVE-2026-100397」をGitHubの脆弱性データベースに載せた。サーバーの認証の処理に欠陥があり、認証なしにrootなど任意のアカウントになりすまして、APIを使われ得る。修正版は7月30日に出ているので、サーバーを動かす組織はバージョンを確かめ、当たる範囲ごとの修正版以降に上げる。advisoryに回避策の記載は無い。

修正前のバージョンが当たる

Rucioは欧州原子核研究機構（CERN）で生まれたデータ管理のソフトウェアで、世界のデータセンターに散らばる大量のファイルの置き場所・複製・転送を管理する。公式サイトの紹介によると、ATLAS・CMSの実験のほか、つくば市の高エネルギー加速器研究機構（KEK）で動くBelle II実験も使っている。GitHubのデータベースの記載では、対象と深刻度は次のとおりだ。

• 対象: PyPIのパッケージ「rucio」
• 当たるバージョンと直ったバージョン: 1.14.0.post1以上35.9.1未満は35.9.1、36.0.0rc1以上38.6.1未満は38.6.1、39.0.0rc1以上40.4.2未満は40.4.2、41.0.0rc1以上41.1.1未満は41.1.1で直った
• CVE番号: CVE-2026-100397
• 深刻度: CVSS 3.1で9.8（GitHubのデータベースの評価）。Rucioの開発チームのadvisoryは10.0とした
• 弱点の種類: CWE-287（不適切な認証）、CWE-305（主な弱点による認証の回避）

原因は、SSHの鍵で認証する時に使う一時的な「チャレンジトークン」の扱いにある。開発チームの説明によると、このトークンは本来、続く鍵の確認のための使い捨ての値だ。ところが、通常の認証トークンと同じデータベースの表に保存され、認証トークンを確かめる関数がこの2つを区別していなかった。チャレンジトークンはアカウント名を指定するだけで認証なしに発行されるため、管理者のアカウントの名前で発行させ、そのまま認証に使えてしまう。

サーバーのバージョンを確認する

まず、自分の組織がRucioのサーバーを動かしているかを確かめる。サーバーのホストかコンテナの中で、Pythonの一般的なコマンド「pip show rucio」を実行し、Versionの欄を見る。上の範囲に入っていれば当たる。

サーバーの外からは、Rucioの公式のクライアントのコマンド「rucio ping」を使える。クライアントの設定と認証情報があれば、pingでつないでいるサーバーのバージョンが返る。問題はサーバーの認証の処理にあるので、バージョンを上げるのはサーバーを動かす側だ。実験の共用のRucioを使うだけの組織は、運用する側に修正の状況を尋ねたい。

範囲ごとの修正版に上げる

修正は、認証トークンを確かめる関数に、チャレンジトークンを認証に使わせない確認を足す数行の変更だ。開発チームは、35系と38系を含む4つの系列に同じ修正を入れ、41.1.1などの修正版を7月30日に出した。リリースノートには「Authentication: Fix SSH challenge tokens」とだけある。

当たる範囲ごとの修正版以降に上げる。35系以前は35.9.1、36系から38系は38.6.1、39系と40系は40.4.2、41系は41.1.1が最初の修正版だ。36系と37系、39系には同じ系列の修正版が無いので、それぞれ38.6.1、40.4.2以降へ系列をまたいで上げる。PyPIの最新は41.5.1だ。advisoryには、すぐ上げられない時の回避策は書かれていない。上げた後は、もう一度「pip show rucio」でバージョンを確かめる。

悪用の報告はまだ無い

CVE-2026-100397は、11月13日の時点で、米サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）の悪用を確認した脆弱性の一覧（KEV）に載っていない。開発チームとGitHubの情報にも、悪用の報告は無い。ただし、なりすましに要るのはサーバーのAPIに届くことと、アカウントの名前だけだ。開発チームのadvisoryは8月11日から公開されている。

SAGUS確認の記録は見当たらず

本稿の第1版の本文には、SAGUSの開発環境で「rucio」をgrepし、端末で「pip show rucio」を実行し、本番のサイトとRolloutのサイトのpingのパスが404だった、と書いてある。しかし、そのgrepの出力、pipの結果、pingの応答を残した記録は、社内に残る記録（執筆の下書き、記事の各版、朝の執筆作業の控え）には見当たらなかった。記録が無いため、SAGUSの環境が当たるかはここでは書かない。サーバーを動かす組織は、上の節の「pip show rucio」と「rucio ping」でバージョンを確かめたい。

編集部の見方

編集部は、この件の要点は修正の中身より、修正から警告までの3か月半の差にあると見る。修正版は7月30日、開発チームのadvisoryは8月11日に出ていたが、GitHubのデータベースに載ったのは11月13日だ。GitHubの説明では、Dependabotの警告はGitHubが確認したadvisoryでしか出ない。Rucioのサーバーを動かす組織は、警告が届いた今日を起点にせず、8月11日から手口が公開されていたものとして上げ、その間のアクセスのログを見直したい。ただし、8月11日より前に修正版に上がっていた環境なら、追加の作業は確認だけで済む。