本文へ移動
English version →
高 9.2 急ぎ度: 早めに

Zipline初期設定の脆弱性、管理者を作成される。4.6.5で修正

セルフホスト型のファイル共有サーバーZipline 4.6.5未満に、初期セットアップの受付を突かれて管理者アカウントを複数作られる脆弱性があります。修正版の4.6.5へ更新し、構築直後に公開していたインスタンスは見覚えのない管理者がいないかも調べてください。

CVE-2026-126937 公開 更新 執筆・監修: 佐々木 航 人が監修しながらAIを活用して執筆
画像は生成 AI で作成したイメージです

急ぎ度: 早めに

CVSS v3は8.1、v4は9.2で、認証なしで管理権限を握られる一方、攻撃には競合状態を突く必要があり、修正版4.6.5がすでに出ています。

関係があるか

Ziplineを自前のサーバーやコンテナーで運用している組織が対象です。とくに、新規構築してから最初の管理者を作るまでの間にネットワークへ公開していた環境が当てはまります。

製品影響を受ける版修正版
Zipline(diced/zipline) 4.6.5未満(GitHubの勧告では4.6.4以前) 4.6.5

確かめ方

  1. 1稼働中のバージョンを確認します。Dockerなら、イメージのタグが4.6.5未満かどうかを見ます。
  2. 2自分のインスタンスに対してだけ、初期セットアップが未完了かどうかを確認します。応答に "firstSetup":true と出れば、セットアップ前の状態です。
  3. 3管理画面のユーザー一覧で、心当たりのないSUPERADMINのアカウントがないかを見ます。

何が起きたか

オープンソースのファイル共有サーバーZiplineに、初期セットアップの受付を悪用されると、管理者権限のアカウントを複数作られてしまう脆弱性が見つかりました。成功すると、攻撃者はインスタンスの管理権限を完全に握ります。

問題があるのは、最初の管理者を作るための POST /api/setup です。初期設定が済んでいないかの確認、SUPERADMINの作成、確認用フラグの更新が、ロックもトランザクションもない3つの別々の操作として実行されます。

パスワードのハッシュ化(argon2)には100〜500ミリ秒ほどかかります。この間に届いた別の要求も、フラグがまだ初期状態のまま確認を通り抜け、それぞれが管理者を作ります。この型はCWE-367(TOCTOU競合状態)に当たります。GitHubの勧告によると、検証環境では20件の同時要求のうち11件が444ミリ秒の間に管理者作成に成功しました。

GitHubの勧告は2026年7月28日付で、CVEとしては2026年11月13日に公表されました。

攻撃の流れ

  1. 1

    未設定の機体

    初期セットアップが済んでいないZiplineがネットワークから届く状態になっている。

  2. 2

    同時に要求

    攻撃者がセットアップ用の受付へ、ごく短い間に多数の要求を同時に送る。

  3. 3

    確認をすり抜け

    ハッシュ化の待ち時間のあいだ、複数の要求がフラグを確認済みとして通過する。

  4. 4

    管理者が複数作成

    通過した要求ごとにSUPERADMINが作られ、攻撃者がログインして管理権限を得る。

公開されている情報をもとにした流れの例です。

どう悪用されるか

認証は不要です。ネットワーク経由で届けば足り、管理者や利用者に何かをさせる必要もありません。ただし、タイミングを合わせて同時に要求を送る必要があり、CVSSでも攻撃の複雑さは高と評価されています。

勧告が示す再現の前提は、空のデータベースで、初期セットアップを完了していないインスタンスです。つまり、構築してから最初の管理者を作るまでの間に外部へ届く状態だったかどうかが分かれ目になります。

ZiplineにはIPアドレスごとの回数制限があります。ただ、要求ごとに異なるX-Forwarded-Forヘッダーを付けると、この制限をかいくぐれます。勧告によると、リバースプロキシ構成で既定の CORE_TRUST_PROXY=true のときに有効です。

悪用に成功すると、攻撃者はインスタンスの管理権限を完全に握ります。機密性・完全性・可用性のいずれもCVSSで高と評価されています。

今すぐやること

  1. 1

    Ziplineを4.6.5に更新する

    稼働中のインスタンスをすべて修正版の4.6.5へ更新します。Dockerの場合は、イメージのタグを確認してから入れ替えます。

    docker ps --format '{{.Names}}	{{.Image}}'
  2. 2

    セットアップ前の状態で残っていないか確認する

    新規に立てたまま管理者を作っていないインスタンスがないかを調べます。応答がfirstSetup:trueなら未完了です。更新するか、いったん外部から届かないようにしてから最初の管理者を作ります。

    curl -s http://127.0.0.1:3000/api/setup
  3. 3

    不審な管理者アカウントを調べる

    公開状態でセットアップ前だった期間があるなら、管理画面のユーザー一覧で心当たりのないSUPERADMINを探します。見つかったら削除し、正規の管理者のパスワードとトークンも変更します。ログイン履歴や外部からの接続記録も見ておくと、侵害の有無を判断しやすくなります。

  4. 4

    新規構築の手順を改める

    今後の構築では、最初の管理者を作り終えてから公開する運用にします。構築中は社内のネットワークや許可したIPアドレスからだけ届くようにしておくと、同種の問題があっても露出を抑えられます。

すぐ更新できないとき

すぐに更新できないときは、まだセットアップが済んでいないインスタンスを外部から届かないようにしたうえで、先に最初の管理者を作り終えます。リバースプロキシやファイアウォールで、接続元を社内や特定のIPアドレスに絞る方法が現実的です。回数制限は偽装したヘッダーで迂回されうるため、防御としては頼れません。

背景

Ziplineは、スクリーンショットやファイルをアップロードして共有リンクを発行するための、自前運用のサーバーです。クラウドの共有サービスを使わず、社内や自分の管理下にファイルを置きたい場面で使われます。管理者アカウントを握られると、そのインスタンスにあるファイルや設定を管理者権限で扱われるおそれがあります。

この脆弱性は、初回に最初の管理者を作る画面を公開しているソフトウェアに固有の弱さです。セットアップが終わるまでの時間は、本来の認証がまだ存在しない状態です。今回のZiplineでは、そこで使われる処理が排他制御なしに書かれていたため、同時に届いた要求が全部通ってしまいました。

よくある質問

Q.すでに管理者を作って運用中のZiplineも、更新しないといけませんか。
A.勧告が示す再現の前提は初期セットアップ前の状態なので、設定済みのインスタンスが同じ方法で狙われる可能性は低いと見られます。それでも、修正版が出ている以上は通常の更新サイクルで4.6.5に上げておくのが安全です。構築直後に公開していた時期があるなら、管理者アカウントの確認だけは先にしてください。

まだ分かっていないこと

  • 実際の攻撃で悪用されたかどうかは、公表されていません。

この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。

影響パッケージ

パッケージ影響を受ける版 → 修正版
dicedzipline
4.6.5 未満→ 4.6.5
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。

Zipline before 4.6.5 contains a TOCTOU race condition in the POST /api/setup endpoint that allows unauthenticated attackers to create multiple SUPERADMIN accounts by racing concurrent requests before the firstSetup flag is reset. Attackers can send simultaneous requests with spoofed X-Forwarded-For headers during the argon2 hashing window to gain full administrative control of the instance.

出典: CVE.org (CVE Program・cvelistV5) NVD

参照URL

当サイトでは、アクセス解析と広告の効果測定のために Cookie を使います。株式会社Game のサイト共通の設定です。 詳しく