OpenStackに乗っ取りの脆弱性 CVE-2026-41283、ログイン済みなら悪用可
自前クラウド基盤OpenStackのワークフロー機能Mistralに、深刻度9.9の脆弱性CVE-2026-41283。ログイン済みの利用者なら誰でも任意コードを実行でき、クラウド全体の認証情報を盗まれる恐れがあります。修正版への更新を。
堀川 慎
Backend Engineer / AWS / Django / Go
自前クラウド基盤OpenStackのワークフロー機能Mistralに、深刻度9.9の脆弱性CVE-2026-41283。ログイン済みの利用者なら誰でも任意コードを実行でき、クラウド全体の認証情報を盗まれる恐れがあります。修正版への更新を。
企業や通信事業者が自前のクラウドを動かすために使う基盤ソフト「OpenStack」の部品のひとつに、深刻度が最高ランクに近い「9.9」と評価された脆弱性が見つかりました。CVE-2026-41283です。問題があるのは、複数の作業を自動でつなげて実行する「ワークフロー」機能を担うMistral（ミストラル）という部品です。
怖いのは、踏み台にするのに特別な管理者権限がいらないことです。そのクラウドに普通にログインできるアカウントが1つあれば、誰でも自分の用意したプログラムをサーバー側で勝手に動かせてしまいます。しかもその先で、クラウド全体を動かすための「サービス用の合鍵」までまとめて盗み出せる可能性があります。OpenStackの開発元は2026年6月3日、修正版とセキュリティ勧告「OSSA-2026-020」を公開しています。
何が起きるのか、まず一言で
今回の脆弱性をかみ砕くと、「権限チェックの掛け忘れ」です。Mistralには外部から命令を受け付ける窓口（API）がいくつもありますが、その一部で「この操作をして良い人かどうか」を確かめる関所が機能していませんでした。本来は管理者しかできないはずの操作が、一般ユーザーでも通ってしまう状態だったのです。
この関所がないせいで、攻撃者は2つのことができます。1つは「誰でも使える公開リソース」を勝手に作ること。もう1つは、そこに自分の書いたプログラムを忍ばせて、Mistralの作業役サーバー（executorワーカー）の上で実行させることです。プログラムが動いてしまえば、あとはそのサーバーが持っている情報を好きに読み出せます。盗み出される代表格が、各サービスをつなぐための認証情報（サービスアカウントのパスワードやトークン）です。
CVE-2026-41283：認可の不備から、任意のコード実行へ
正式な分類はCWE-863（誤った認可）。米国の脆弱性データベース（NVD）は深刻度を10点満点中9.9（Critical）としました。攻撃に必要な条件はネットワーク経由でのアクセスと低い権限のアカウントだけで、利用者の操作を待つ必要もありません。Mistralの窓口（API）を外部やテナントから触れる形で公開している環境がそのまま影響を受けます。「任意のコード実行」、つまりサーバーの乗っ取りに直結する、クラウド基盤としては最も避けたいタイプの欠陥です。
OpenStackとMistralは、そもそも何をする道具なのか
OpenStackは、ひとことで言えば「自分の会社やデータセンターの中に、AWSのようなクラウドを丸ごと作るためのソフト」です。サーバー・ストレージ・ネットワークをまとめて管理し、利用者は必要なときに仮想マシンを立ち上げたり消したりできます。通信事業者の基盤、大学や研究機関の計算環境、官公庁や大企業のプライベートクラウドなど、表に出にくいところで広く使われています。今回の発見者の1人が大手クラウド事業者OVHcloudの技術者である点も、利用層の厚さを物語っています。
そのOpenStackの中で、Mistralは「決まった手順の自動化」を引き受ける部品です。たとえば「仮想マシンを5台立てて、設定を流し込んで、できあがったら通知する」といった一連の作業を、YAMLという書式で手順書（ワークフロー）として書いておくと、Mistralが順番に実行してくれます。TripleOと呼ばれるOpenStack自身の構築ツールがこのMistralを土台にしてきたこともあり、クラウドの「裏方の自動化エンジン」として組み込まれている例は少なくありません。
手順書を実際に動かす役割を担うのが「executorワーカー」です。ここが他のサービスと連携して仕事を進めるため、ワーカーの手元には各サービスへの接続情報が集まります。つまりMistralのワーカーは、クラウドの自動化の中枢であると同時に、合鍵が集まる金庫でもあります。今回の脆弱性は、その金庫の前の関所が開きっぱなしだった、という話です。
概要を1分で
細かい説明に入る前に、要点を表にまとめます。いちばん効くのは「Mistralを動かしていて、そのAPIに一般利用者が触れる環境かどうか」の確認です。社内専用・管理者しか触れない構成であれば、即座に乗っ取られる危険は下がります。
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-41283（勧告 OSSA-2026-020） |
| 対象 | OpenStack Mistral （ワークフローサービス） |
| 深刻度 | 9.9 / 10（Critical・CVSS 3.1） |
| 種別 | 認可の不備（CWE-863） → 任意コード実行 |
| 攻撃の条件 | ネットワーク経由＋ ログイン済みの一般アカウント |
| 影響バージョン | 20.0.0以上 20.1.1未満 ／ 21.0.0 ／ 22.0.0 |
| 修正 | 20.1.1 ほか各系列の修正パッチ （2026年6月3日公開） |
| 悪用状況 | KEV未登録・実証コード未公開 （2026年6月4日時点） |
同じ「ログイン後に権限の壁を越える」型の事故は、認証基盤やSSO製品でも繰り返し起きています。最近ではシングルサインオン基盤Casdoorの認証回避や問い合わせ管理OTRSの認可回避も同系統で、今回のMistralはそれをクラウド基盤の規模でやってしまった格好です。
社内の一般アカウント1つが、クラウドの管理者鍵束に化けるとき
この脆弱性の本当の怖さは、攻撃の入口が「管理者」ではなく「ただログインできる人」である点に尽きます。狙ってくるのは、退職間際で会社に不満を抱えた委託先のエンジニア、盗んだAPIトークンを握って入り込んだ侵入者、そして同じクラウドに相乗りしている別テナントの悪意ある契約者です。彼らが触れるのは最初こそ自分の小さな権限だけですが、Mistralの開いた窓口を通せば、executorワーカーのOS権限、各サービスをつなぐサービスアカウントのパスワードとトークン、他テナントが登録したワークフローの中身、そこに書かれた接続先の情報までが射程に入ります。関所の壊れたAPIに手を伸ばした瞬間、一般利用者の権限しか持たないはずの人物が、クラウドの裏側で動く合鍵束を丸ごと手にしてしまうのです。
盗み出されたサービス用の合鍵は、そのまま次の被害の燃料になります。攻撃者はその鍵で仮想マシンを動かすNova、ネットワークを握るNeutron、保存データを抱えるCinderやSwiftといった中枢に正規の顔で入り込み、他テナントの仮想マシンに勝手に侵入して暗号通貨の採掘プログラムを仕込んだり、保存データを丸ごと吸い出したり、業務システムを人質に取って身代金を要求したりできます。さらに、奪ったクラウドへのアクセスそのものが闇市場で売買され、別の犯罪グループの侵入口として転売されていきます。1つの相乗りアカウントの油断が、同じ基盤に乗る無関係な顧客全員の被害に化けるのが、共有インフラの怖いところです。
そして、その後始末の責任は使った側ではなく、クラウドを運用する事業者や社内の情報システム部門に返ってきます。個人情報が流出すれば個人情報保護委員会への報告と本人への通知が必要になり、相乗り顧客への説明と賠償、停止したサービスのSLA違反、そして「あの基盤は危ない」という評判の失墜が一度に押し寄せます。9.9という数字は技術的な深刻度の天井を示すだけで、運用側が現実に背負うコストはそこには載っていません。だからこそ、攻撃者がこの穴を見つけるより先に塞げるかどうかが、相乗りしている全員の安全を左右します。
なぜ起きたのか、技術的に見ると
開発元のセキュリティ勧告と、公開メーリングリスト（oss-security）への投稿によると、根本原因は「複数のMistral APIエンドポイントがアクセスポリシーを適用していなかった」ことです。OpenStackでは通常、各操作に対して「この役割（ロール）の人だけ許可する」というポリシー（oslo.policyに基づく認可ルール）が設定されます。ところがMistralの一部の窓口では、このチェックが抜けており、トークンさえ持っていれば誰でも操作が通ってしまいました。
攻撃の流れはこうです。まず認可チェックの抜けた窓口を使って、誰からでも参照・利用できる「公開リソース」を作成します。Mistralのワークフローやアクションは、内部で外部コマンドやスクリプトを呼び出す仕組みを持っているため、この公開リソースに攻撃者が自分のコードを仕込めます。仕込まれたコードは、ワークフローを実際に処理するexecutorワーカーの上で実行されます。ワーカーはクラウド内の各サービスと連携するために認証情報を手元に持っているので、攻撃者はそこからサービスアカウントの資格情報を抜き出せる、という連鎖です。
この「外部から渡された定義が、そのままサーバー側で実行される」という構図は、目新しいものではありません。たとえばAI開発ツールLangflowの認証なしRCE、通信基盤Apache MINAのデシリアライゼーションRCE、ファイル共有Sambaの認証なしRCEでも、入口の検証不足が任意コード実行に化けました。違うのは、Mistralの場合その実行先がクラウド全体の管理レイヤーである点です。実証コード（PoC）は今のところ公開されていませんが、構造が単純なだけに、再現はそれほど難しくないと見るべきでしょう。
影響を受けるバージョンと、修正の状況
勧告OSSA-2026-020が示す影響範囲と、対応するOpenStackのリリース系列は次のとおりです。OpenStackは半年ごとに「Epoxy」「Flamingo」といったコードネームのリリースを出しており、Mistralのバージョン番号もそれに対応しています。
| OpenStackリリース | Mistralの影響バージョン | 対応 |
|---|---|---|
| 2025.1（Epoxy） | 20.0.0以上 20.1.1未満 | 20.1.1へ更新 |
| 2025.2（Flamingo） | 21.0.0 | 系列の修正パッチを適用 |
| 2026.1（Gazpacho） | 22.0.0 | 系列の修正パッチを適用 |
| 2026.2（Hibiscus） | 開発中ブランチ | 修正反映済み |
修正は2026年6月3日に、上記4つの安定版系列（2025.1〜2026.2）すべてに対して同時にリリースされました。20.x系列を使っている環境は20.1.1へ、21.0.0・22.0.0を使っている環境はそれぞれの系列に出た修正版へ更新するのが基本対応です。Red Hat OpenStack Platformのようなディストリビューション版を使っている場合は、提供元から配布されるパッケージ更新を待って適用してください。なおLaunchpadのバグ番号は2147178です。
今すぐやるべきこと
最優先は、Mistralを更新することです。20.1.1または利用中の系列の修正版に上げれば、抜けていた認可チェックが入ります。更新までに時間がかかる場合の応急処置として、Mistralのapi（窓口）に誰がアクセスできるかを絞り込んでください。具体的には、Mistral APIをインターネットや一般テナントから直接触れない位置に置き、信頼できる管理ネットワークやオーケストレーション基盤からのみ到達できるよう、ファイアウォールやセキュリティグループで制限します。勧告も「Mistral APIを公開している環境が影響を受ける」と明記しており、公開範囲の見直しがそのまま被害確率を下げます。
あわせて、すでに踏まれていないかの点検も必要です。Mistralのログで、見覚えのない公開ワークフロー・アクションの作成、想定外のアカウントによるAPI呼び出し、executorワーカー上での不審なプロセス起動がないかを確認します。万一悪用された場合、最も警戒すべきは「サービスアカウントの認証情報がすでに抜かれている」前提での二次被害です。その想定に立つなら、影響範囲のサービスアカウントのパスワード・トークンを更新（ローテーション）し、Keystoneの認証ログで横展開の痕跡を追うところまでがワンセットになります。秘密鍵やトークンが漏れたときの後追いの難しさは、Cloud Foundryの認証サーバーで秘密鍵が漏えいした事例でも触れたとおりです。盗まれたサービス認証情報が他システムへの侵入の踏み台に転用されていく流れは、オープンソース部品を経由した攻撃の連鎖とも地続きで、Mistralのようにオープンソースで広く使われる基盤ほど影響範囲が読みにくくなります。
検知と緩和のチェックポイント
自分の環境がどれくらい危ないかを素早く見極めるための観点を、影響の大きい順に並べます。これは更新作業の優先度を決める助けにもなります。
| 確認する点 | 危険度の目安 |
|---|---|
| Mistral APIを 一般テナント／外部に公開している | 最も危険（即更新） |
| Mistralは動かしているが APIは管理網に限定 | 要更新（内部脅威に注意） |
| 影響バージョンを 使っていない／未導入 | 直接の影響なし |
注意したいのは、「APIを管理網に限定しているから安全」とは言い切れない点です。今回の攻撃条件は「ログイン済みの一般アカウント」であり、社内の委託先や相乗りテナント、盗まれたトークンといった内部に近い経路からの悪用が成立します。外部公開していなくても、影響バージョンを動かしている限り更新は必要です。なお本脆弱性は2026年6月4日時点でCISAの「悪用が確認された脆弱性カタログ（KEV）」には登録されておらず、実証コードの公開も確認されていません。とはいえ修正内容から手口が推測されやすいため、登録を待たずに動くのが賢明です。
これまでの経緯
発見から修正版公開までの流れを時系列で整理します。脆弱性は公開前にOpenStackの脆弱性対応チーム（VMT）へ非公開で報告され、修正の準備が整ってから一斉に公表される手順が取られました。
← スワイプで移動
よくある質問
Q. うちはOpenStackを使っていますが、Mistralを入れた覚えがありません。影響はありますか？
A. Mistralはオプション的な構成要素なので、導入していなければ今回の脆弱性の直接的な影響はありません。ただし、OpenStack自身の構築・運用ツールがMistralを内部で使っている場合があります。心当たりがなくても、`mistral-api`や`mistral-executor`といったサービスが動いていないか確認しておくと安心です。
Q. 一般ユーザー権限が必要なら、それほど危険ではないのでは？
A. クラウド基盤では「一般ユーザー」の母数が非常に多いのが落とし穴です。各テナントの利用者、自動化を回すCIのサービスアカウント、委託先の作業用アカウントなど、トークンを持つ主体は無数にいます。そのどれか1つが乗っ取られたり悪用されたりすれば成立するため、深刻度は9.9と高く評価されています。「管理者でなければ安全」という前提が崩れているのが本件の要点です。
Q. すぐにバージョンを上げられません。最低限の応急処置は？
A. Mistral APIにアクセスできる範囲を絞るのが最優先です。インターネットや一般テナントから直接到達できないよう、信頼できる管理ネットワーク経由に限定してください。あわせて、Mistralのログで不審な公開リソースの作成やAPI呼び出しがないかを点検し、疑わしい場合はサービスアカウントの認証情報を更新します。これは更新までの時間稼ぎであり、根本対策はあくまで修正版への更新です。
Q. すでに攻撃されているかどうかは、どう確認すればいいですか？
A. 確実な判定は難しいものの、Mistralのログにある見覚えのない公開ワークフロー・アクションの作成記録、想定外のアカウントによるAPI呼び出し、executorワーカー上の不審なプロセスやアウトバウンド通信が手がかりになります。サービスアカウントの認証情報が漏れた前提に立ち、Keystoneの認証ログで他サービスへの異常なアクセスがないかまで追うのが安全です。実証コードは未公開ですが、痕跡が残らない攻撃ではない点が救いです。