データ基盤『Prefect』に乗っ取りの穴 CVE-2026-5366、最新版へ更新を
Pythonでデータ処理を自動化する人気ツール『Prefect』に、サーバー上でコードを実行され乗っ取られる重大な欠陥が見つかりました。深刻度はCVSS 9.9。複数人で使う共有環境では、作業を登録できる権限さえあれば他の利用者の処理基盤まで乗っ取られる恐れがあります。修正版が出ており、自分で運用している場合は早急な更新が必要です。
堀川 慎
Backend Engineer / AWS / Django / Go
Pythonでデータ処理を自動化する人気ツール『Prefect』に、サーバー上でコードを実行され乗っ取られる重大な欠陥が見つかりました。深刻度はCVSS 9.9。複数人で使う共有環境では、作業を登録できる権限さえあれば他の利用者の処理基盤まで乗っ取られる恐れがあります。修正版が出ており、自分で運用している場合は早急な更新が必要です。
Pythonでデータ処理の流れ（パイプライン）を組んで自動実行する人気ツール「Prefect」に、サーバー上で任意のプログラムを実行されてしまう重大な欠陥が見つかりました。CVE-2026-5366、深刻度はCVSS 9.9（最高10.0）です。日本時間6月21日（米国時間6月20日）に米国の脆弱性データベースNVDが登録しました。修正はPR #21384で取り込まれ、3.6.25.dev7以降で直っています。それより前のバージョンを自分で運用している場合は、最新版への更新が必要です。
問題は、Prefectがgit（ソースコードの保管・取得の仕組み）からパイプラインのコードを取ってくる部分にあります。取得時に指定する「コミット番号（commit_sha）」や「取得対象フォルダ（directories）」の値が、検証されないままgitコマンドの引数としてそのまま渡されていました。攻撃者はここに、ただの番号のふりをしたgitへの命令（オプション）を紛れ込ませることができます。これがいわゆる「引数インジェクション」で、結果として、実際に処理を動かすワーカー（作業マシン）の上で任意のコマンドが実行されてしまいます。
怖いのは、踏むのに高度な権限が要らないことです。Prefectを社内の複数人やチームで共有して使っている環境では、「作業（デプロイ）を登録できる」程度の権限を持つ利用者なら誰でもこの穴を突けます。しかもCVSSの評価は、影響が自分の枠を越えて共有ワーカーや他の利用者の処理基盤にまで及ぶこと（スコープの変更）を織り込んでの9.9です。1人分のアカウントが、共有基盤全体への入口になりかねません。
Prefectとは何をするツールか
Prefectは、Pythonで書いたデータ処理を「いつ・どの順番で・失敗したらどう再実行するか」まで含めて自動で回すためのオープンソースのツールです。データの取り込み、集計、機械学習の前処理といった定期的な処理を、人手をかけずに安定して動かすために使われます。この分野（ワークフローオーケストレーション）の代表格のひとつで、GitHubのスター数は1万7千を超えます。Apache Airflowなどと並んで、データエンジニアリングの現場で広く採用されています。
使い方は大きく2通りです。ひとつはPrefect Cloudという運営会社の管理サービスを使う方法、もうひとつが「Prefect Server」を自分のサーバーに置いて動かすセルフホストです。今回の欠陥が効くのは主に後者、とくに1つのPrefect環境を複数のチームや利用者で共有しているケースです。
Prefectの典型的な構成では、利用者が「このgitリポジトリのこのコードを動かして」と作業（デプロイ）を登録し、ワーカーと呼ばれる実行役のマシンが、そのコードをgitから取得して実行します。このワーカーは、データ処理を実際に行う立場上、データ倉庫やクラウドの強い権限、各種パスワードや秘密鍵を握っていることがほとんどです。乗っ取られたとき何が流れ出るのかは、ここを押さえてから読むと分かりやすくなります。
「番号のふり」をした命令1つで、データ基盤を握る者は何を持っていくのか
CVSS 9.9という数字を見ても自分の損失には結びつきにくいので、先に「誰が、何を目当てに、Prefectのワーカーに手を伸ばすのか」を具体的に描いておきます。Prefectのワーカーが置かれているのは、会社のデータと、そのデータを動かすための鍵束が集まる場所です。そこを開けられると何が出るかが、この欠陥の本当の怖さです。
この穴を踏むのは、遠い国のハッカー集団とは限りません。むしろ動機が生々しいのは、業務委託で一時的にアカウントを持っている外部スタッフ、退職を控えて持ち出しを企てる現職、フィッシングで社員1人分のログインを盗んだだけの侵入者です。彼らに必要なのは「作業を登録できる」最低限の権限だけで、それさえあればワーカー上でコマンドを動かせます。狙うのは抽象的な「データ」ではなく、データ倉庫（Snowflakeやデータベース）の接続パスワード、AWSやGCPのアクセスキー、Prefectに保存された各種トークン、そしてパイプラインを流れていく顧客データそのものという、具体的な現物です。番号に見せかけたgitオプションを1つ送り込めた瞬間、ワーカーが握る鍵束ごと相手の手に渡り、処理基盤が乗っ取られてしまいます。
サイバー攻撃の言葉で言うと、データ基盤のワーカーは「横展開」の理想的な踏み台です。ワーカーはクラウドや社内ネットワークの奥に置かれ、データ倉庫や本番データベースへ正規に接続できる立場にいます。そこを起点にすれば、攻撃者は本来アクセスできないはずのシステムへ次々と侵入を広げられます。さらに今回はスコープの変更を伴う欠陥のため、自分のチームの枠を越えて、同じワーカーを共有する他チームの処理や認証情報にまで手が届きます。マルチテナント（1つの基盤を複数の利用者で共有する形）で運用しているほど、被害は1人の枠で止まりません。
CVSS 9.9はあくまで技術的な深刻度の目盛りにすぎません。Prefectでデータ基盤を回している会社にとって本当に痛いのは、サーバーが一時的に落ちることではなく、データ倉庫とクラウドの鍵が丸ごと外に出て、顧客データの流出と他チーム領域への侵入が同時に起きることです。自動化のための便利な仕組みが、そのまま全社のデータへの最短経路になっていた、という結末になりかねません。
CVE-2026-5366：gitの引数に命令を紛れ込ませる仕組み
CVE-2026-5366: GitRepositoryのコミット番号からの引数インジェクション（CVSS 9.9）
CVE-2026-5366は、Prefectがgitリポジトリからコードを取得する処理（GitRepositoryストレージ、ファイルでいうとsrc/prefect/runner/storage.py）に存在します。NVDの分類はCWE-94（コード生成の不適切な制御）。CVSSは9.9で、攻撃に必要な権限が低い（PR:L）一方、影響が範囲外に及ぶ（スコープ変更）と評価されています。
利用者が作業を登録するとき、「どのコミットのコードを使うか」を示すcommit_shaと、「どのフォルダを取得するか」を示すdirectoriesを指定できます。本来commit_shaはa1b2c3d...のような16進数の番号のはずです。ところがPrefectはこの値を検証せず、そのままgitコマンドの引数として渡していました。
ここが落とし穴です。gitのようなコマンドは、引数の先頭が--で始まると「これは値ではなくオプション（命令）だ」と解釈します。攻撃者がcommit_shaに番号の代わりに--upload-pack=touch /tmp/pwnedのような文字列を入れると、gitはこれをオプションとして受け取り、攻撃者が指定したコマンドを実行してしまいます。報告と公開検証はバグ報奨金プラットフォームhuntrを通じて行われました。
なぜ「git の引数」がコマンド実行になるのか
この攻撃が成立する鍵は、gitが持つ「外部プログラムを呼び出すオプション」にあります。たとえば--upload-packや--execといったオプションは、リポジトリ取得の途中で指定されたプログラムを起動する仕組みです。本来は正規の運用のためにある機能ですが、攻撃者が値を自由に決められると、これが任意コマンド実行の引き金に変わります。
この「ユーザー入力をそのままコマンドの引数に渡してしまう」型の欠陥は、Prefect固有の珍しいものではなく、git連携を持つツール全般で繰り返し起きています。2026年4月には、GitHub本体でも単一のgit pushから遠隔操作につながるCVE-2026-3854が公表されました。便利な自動化のために外部から値を受け取る場所ほど、「その値は本当に番号か、それとも命令か」を入口で見分ける必要があります。本サイトでもLangflowのtarリンク悪用など、入力検証の欠落が乗っ取りに直結した事例を継続的に取り上げています。
修正の中身と、AIが書いた修正PR
開発元はPR #21384で、入口での値チェックを追加して対処しました。具体的には、commit_shaを正規表現^[0-9a-fA-F]{4,64}$（16進数で4〜64文字）に限定し、命令の形をした値をコマンド実行前にはじくようにしています。下限の4文字はgitが許す最短の短縮番号、上限の64文字はSHA-1（40文字）とSHA-256（64文字）の両方に対応する長さです。あわせて、directoriesが--で始まる場合に警告を出し、git sparse-checkout setに「ここから先は値」と区切る--を追加しています。
この修正PRが、開発支援AI「Devin」によって自動生成され、2026年4月2日にメンテナによってマージされた点も今回の特徴です。AIエージェントがセキュリティ修正のコードを書き、人間が確認して取り込むという流れが、実際の重大脆弱性の修正で動いていることを示す一例でもあります。修正版は3.6.25.dev7として配布されており、影響を受けるのはそれより前（3.6.25.dev6まで）のバージョンです。
自分のPrefectは対象か（バージョン別早見表）
セルフホストでPrefectを動かしている場合、まずは下の表で自分の状況を確認してください。クラウド版（Prefect Cloud）を使っている場合は、サーバー側は運営によって対処されます。
| 運用形態 / バージョン | CVE-2026-5366の影響 | 対処 |
|---|---|---|
| セルフホスト 3.6.25.dev6まで | 対象（とくに 共有環境で危険） | 最新版へ更新 |
| セルフホスト 3.6.25.dev7以降 | 修正済み | アクセス権限の 見直しを推奨 |
| Prefect Cloud | サーバー側は 運営が対処 | ワーカーの 更新を確認 |
注意したいのは、セルフホストでもクラウドでも、実際に処理を動かすワーカー（作業マシン）は自分たちの環境で動かしていることが多い点です。サーバー本体が直っても、古いPrefectのワーカーが残っていれば穴は塞がりません。ワーカー側のバージョンもあわせて確認してください。
いますぐやるべきこと
1. Prefectを最新版に更新する。 サーバーとワーカーの両方を、修正の入った3.6.25.dev7以降（できればその後の安定版）に更新します。Pythonパッケージとして入れている場合はpip install -U prefect、Dockerの場合は最新イメージを取得してワーカーを作り直します。サーバーだけでなく、コードを取得・実行するワーカーの更新を忘れないでください。
2. 誰がデプロイを登録できるかを見直す。 この欠陥は「作業を登録できる権限」さえあれば踏めます。共有環境では、本当に必要な人だけがデプロイを作れるよう権限を絞り、不要になった外部スタッフや退職者のアカウントを停止します。誰でも自由にパイプラインを登録できる状態は、それ自体がリスクです。
3. ワーカーが握る鍵を入れ替える。 対象バージョンを共有環境で運用していた場合、ワーカーからアクセスできたクラウドのアクセスキー、データ倉庫やデータベースの接続情報、Prefectに保存したトークン類は漏れた前提で再発行します。とくにAWS/GCPのキーは影響が広いため優先します。
4. ワーカーの権限を最小限にする。 今回のような事故の被害を小さくする根本対策は、ワーカーに与える権限をそもそも絞ることです。1台のワーカーに全データへの強い権限を持たせるのではなく、処理ごとに必要最小限の権限だけを渡す設計に見直します。
5. 侵害の痕跡を点検する。 ワーカーのマシンで、ps auxに見慣れないプロセス、/tmpや/var/tmpに身に覚えのない実行ファイル、不審なcron登録や外向き通信がないかを確認します。心当たりがあれば、クリーンな環境への作り直しが最も確実です。
攻撃中CVEの一覧と関連記事
2026年6月時点で、CVE-2026-5366は米政府CISAが公開する「実際に攻撃されている脆弱性リスト（KEV）」には登録されていません。とはいえ、CWE-94（コード注入）でCVSS 9.9という評価は最高クラスで、データ基盤という性質上、内部関係者や乗っ取られたアカウントからの悪用が現実的なリスクです。攻撃が確認されたCVEの最新状況は、本サイトのCISA KEVダッシュボード（日本語版）で随時更新しています。
Prefectのようにpipで配布されるOSSの脆弱性は、依存関係をたどって思わぬところに影響が広がります。利用中のパッケージに既知の穴がないかは、OSSサプライチェーン・スキャナーから確認できます。同じ「外部入力をそのまま実行してしまう」型の事故は、本サイトでもAI構築ツールFlowiseのoverrideConfig欠陥やLiteLLMのコマンド注入など、開発・データ系ツールで繰り返し起きています。
まとめ
CVE-2026-5366は、Prefectがgitからコードを取得するときに、利用者が指定した「コミット番号」をそのままgitコマンドの引数に渡していたために生まれた、引数インジェクションの欠陥です。番号のふりをしたgitオプションを送り込むだけで、処理を動かすワーカー上で任意のコマンドが実行され、CVSSは9.9と評価されています。修正はPR #21384で取り込まれ、3.6.25.dev7以降で直っています。
この穴の本当の怖さは、踏むのに高度な権限が要らず、影響が共有基盤の他の利用者にまで及ぶ点です。データ基盤は、データそのものとそれを動かす鍵束が集まる場所で、1つ乗っ取られると被害が連鎖します。セルフホストでPrefectを使っているなら、サーバーとワーカーの更新に加えて、「誰がデプロイを登録できるか」「ワーカーがどこまでの鍵を握っているか」を、この機会に一度棚卸ししておくことをおすすめします。