OpenStack Mistral RCE脆弱性（CVE-2026-41283 / CVSS 9.9）｜低特権認証→executor RCEの確認と修正手順

2026年6月3日、OpenStackのセキュリティチームは、ワークフローエンジンMistralに深刻な脆弱性があるとしてOSSA-2026-020を公開した。割り当てられたCVE-2026-41283はCVSS 9.9（Critical）で、Mistralの一部APIエンドポイントが認可ポリシーを適切に適用していないために、低特権の認証ユーザーが公開リソースの不正作成とexecutorワーカー上での任意コード実行（RCE）に至り、最終的にサービス認証情報の窃取まで連鎖する。本記事では、この脆弱性の正確な意味と、自環境での確認・修正・暫定対策の手順を解説する。

AIエージェント時代のクラウド/OSSセキュリティ全体像を整理したい方は、ピラー記事AIセキュリティとは？LLM時代の脅威モデル・代表的リスク・OSS対策ツールを体系解説する入門ガイドを先に読むと、本記事の位置づけがつかみやすい。

30秒で理解する

この記事で繰り返し強調するのは、見出しだけ読んで「未認証で誰でも攻撃できる」と誤読しないことだ。攻撃には有効なアカウントが要る。だが、その敷居は「低特権ロールで足りる」ほど低く、奪える成果（executor上のサービス認証情報）は重い。だからこそ優先度はCriticalであり、後回しにできない。

何が起きたか

OSSA-2026-020は、OVHcloudのEduardo Gonzalez Gutierrez氏とArnaud Morin氏による報告を受けて、2026年6月3日にoss-securityメーリングリストおよびOpenStack Security Advisoriesで公開された。タイトルは「Mistral policy enforcement bypass allows unauthorized public resource creation and arbitrary code execution」——直訳すれば「Mistralのポリシー適用バイパスにより、不正な公開リソース作成と任意コード実行が可能」だ。翌6月4日にはNVDがCVE-2026-41283として登録し、CVSS 9.9を割り当てている。

OpenStack環境におけるこの問題の意味は単純ではない。Mistralは「ユーザーが定義した処理を、他のOpenStackサービスに対して自動実行する」立場にある。つまりexecutorは、Nova・Neutron・Cinder・Keystoneといったサービスを呼び出すための認証情報を手元に持つ。その実行基盤に低特権ユーザーから任意コードを送り込めるなら、奪える情報はMistral単体に閉じない。CVSSのScope:Changed（権限境界を越える）が示すのは、まさにこの「最初は低特権でも、最終的に基盤全体に波及しうる」性質である。

なお報道の一部では本件を「未認証RCE」「認証不要」と表記しているものがあるが、これは誤りだ。NVDが確定したベクトルはPR:Lであり、攻撃には有効な認証が必要である。本記事では一次ソース（OSSA-2026-020とNVD）の表記に従う。関連する直近のRCE/サプライチェーン事例として、Vitest RCE脆弱性（CVE-2026-47429ほか）の確認・パッチ手順や、トークン窃取を多層で止める防御パターンも併せて押さえておくと、今回の「認証情報窃取からの横展開」というシナリオへの備えがつかみやすい。

OpenStack Mistralとは

Mistralは、OpenStackの公式プロジェクトの一つであるワークフローサービス（Workflow as a Service）だ。YAMLで記述したワークフロー定義（タスクの依存関係・並列・リトライ・条件分岐など）を受け取り、各タスクを他のOpenStackサービスやスクリプトとして実行する。長時間バッチ、定期ジョブ、複数サービスをまたぐオーケストレーションなどに使われ、Heatや各種運用自動化の裏側で動いていることも多い。

アーキテクチャは大きく5つのコンポーネントで構成される。役割を理解しておくと、今回の攻撃面と隔離策の意味がつかみやすい。

ここで鍵になるのはTask Executorだ。executorは「ワークフローに書かれたとおりの処理」を実行するのが仕事であり、その処理が外部サービスを叩く以上、相応の認証情報を持つ。攻撃者の狙いは、APIのポリシーバイパスを入口にして、このexecutorに自分の意図したコードを実行させ、手元の認証情報を吐き出させることにある。

脆弱性の詳細

CVE-2026-41283の本質は、CWE-863（Incorrect Authorization、不適切な認可）だ。Mistralの複数のAPIエンドポイントが、本来課すべき認可ポリシー（policy.yamlで定義されるロールベースのアクセス制御）を適用しておらず、結果として認証は通った低特権ユーザーが、本来許されないリソース作成・公開操作を実行できてしまう。公開リソースとして登録されたワークフローやアクションがexecutorで実行される過程で、任意コード実行へと到達する。

CVSSベクトルを分解すると、危険度の根拠がはっきりする。

ベクトル文字列はAV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H、ベーススコアは9.9。PR:Lが「未認証ではない」ことを、Scope:Changedが「最初の足がかりが低特権でも基盤全体に波及しうる」ことを、それぞれ示している。9.9という値は、PR:Lの分だけ満点の10.0から僅かに下がっただけ、と読むのが正しい。

攻撃の連鎖を図にすると次のようになる。実際のペイロードは本記事では扱わず、検知・修正の観点に絞る。

影響を受けるバージョンと、対応の方向性を整理する。OSSA-2026-020が示す影響範囲は次のとおりだ。

修正はupstream（OpenDevレビュー）で2025.1/epoxy・2025.2/flamingo・2026.1/gazpacho・2026.2/hibiscusの各ブランチに反映されている。ディストリビューション（Red Hat OpenStack Platform、Ubuntu Cloud Archive、Kolla等）を使っている場合は、各ベンダーのパッケージ更新を待ち、リリースノートで本CVEの修正取り込みを確認するのが確実だ。詳しいバージョン番号は記事末尾の一次ソースで最新を確認してほしい。

⚡対応確認の手順（重点）

ここからが実務の中心だ。まず「自分の環境が対象か」を切り分け、対象なら影響範囲を棚卸しする。すべて検知・確認用のコマンドで、攻撃手法は含まない。

Step 1: Mistral使用有無

Mistralがサービスカタログに登録され、プロセスが稼働しているかを確認する。直接使った覚えがなくても、HeatやTackerから内部呼び出しされている場合があるため、必ず実機で確認する。

# サービスカタログにMistral（workflowv2）が登録されているか
openstack service list | grep -i mistral
openstack endpoint list --service workflowv2

# プロセス／ユニットの稼働確認
systemctl status mistral-api mistral-engine mistral-executor 2>/dev/null
ps aux | grep -E 'mistral-(api|engine|executor)' | grep -v grep

カタログにworkflowv2が無く、mistral-apiプロセスも動いていなければ、本CVEの直接対象ではない。逆に1つでも該当すれば、次のStepへ進む。

Step 2: バージョン確認

影響バージョン（20系の20.1.1未満、21.0.0、22.0.0）に該当するかを、導入形態に応じて確認する。

# pip／venv 内（DevStack・ソース導入）
pip show mistral 2>/dev/null | grep -E '^(Name|Version)'

# RPM系（RHEL/CentOS/Rocky、RHOSP含む）
rpm -qa | grep -i openstack-mistral

# Deb系（Ubuntu/Debian、Ubuntu Cloud Archive）
dpkg -l | grep -i mistral

# Kolla／コンテナ運用
docker exec mistral_api pip show mistral 2>/dev/null | grep -i version

該当バージョンなら、Step 3〜4で影響棚卸しを行いつつ、後述の修正手順でパッチ適用を進める。

Step 3: 低特権ロール棚卸し

攻撃に必要なのは「低特権の認証ユーザー1つ」だ。誰がMistralに到達できるロールを持っているかを洗い出し、不要な割り当てを削る。

# Keystone のロール定義一覧
openstack role list

# プロジェクト×ユーザーのロール割り当て（名前表示）
openstack role assignment list --names

# 特定ユーザーの権限を個別確認
openstack role assignment list --user <user-name> --names

確認の観点は次のとおりだ。 ・退職者・異動者・テスト用に作ったまま放置したアカウントが、memberなどの低特権ロールを保持していないか
・自動化用のサービスアカウントに、必要以上の広いロールが付いていないか
・本来Mistralを使わないテナントのユーザーが、workflowv2に到達できる状態になっていないか

不要な割り当てを削除し、最小権限に寄せておくと、パッチ適用までの暫定的なリスク低減になる。

Step 4: 認証ログ確認

すでに悪用された痕跡がないかを、KeystoneのトークンとMistral APIのアクセスログで突き合わせる。

# Keystone のトークン発行・認証ログ（配置はディストリにより異なる）
journalctl -u devstack@keystone 2>/dev/null | grep -i token | tail -50
grep -iE 'token|authenticate' /var/log/keystone/keystone.log 2>/dev/null | tail -50

# Mistral API の作成系リクエスト（POST/PUT）を抽出
journalctl -u mistral-api --since "7 days ago" 2>/dev/null | grep -E 'POST|PUT' | tail -80
grep -E 'workflows|actions|executions' /var/log/mistral/api.log 2>/dev/null | tail -80

普段ワークフローを作らないアカウントによる作成・公開リクエスト、見覚えのない公開リソース、executorからの想定外の外部通信が見つかれば、保全のうえで精査する。

⚙️ 修正手順

切り分けが済んだら、パッチ適用が本筋の対策だ。ポリシー検査の修正そのものはパッチでしか入らないため、暫定策はあくまで「適用までの時間稼ぎ」と位置づける。

A. パッケージアップデート

導入形態に応じて最新の修正版へ更新し、Mistralの各プロセスを再起動する。

# RPM系
sudo yum clean all && sudo yum update 'openstack-mistral*'

# Deb系
sudo apt update && sudo apt install --only-upgrade python3-mistral mistral-common

# pip／venv（20系なら20.1.1以上を明示）
pip install --upgrade 'mistral>=20.1.1'

# 反映のため再起動
sudo systemctl restart mistral-api mistral-engine mistral-executor

更新後はpip show mistral等で再度バージョンを確認し、修正版になっていることを担保する。

B. クラスタ環境での無停止更新

APIノードやexecutorを複数並べている本番環境では、サービス断を避けてローリング更新する。Engineが未完了タスクを再スケジュールする性質を活かし、executorは1ノードずつ落として更新する。

# executor を1ノードずつ：停止 → 更新 → 起動
sudo systemctl stop mistral-executor
pip install --upgrade 'mistral>=20.1.1'   # ディストリ環境はyum/apt
sudo systemctl start mistral-executor

# API ノードはロードバランサから外して順次更新し、戻す
# （LB側でドレイン → 更新 → ヘルスチェック通過後に復帰）

全ノードの更新完了後に、改めてバージョンとAPIの疎通を確認する。

C. アップデート不可な場合の暫定対策

メンテナンス枠が取れず即時パッチが難しい場合の、時間稼ぎとしての多層緩和策だ。いずれも根本対策ではない点に留意する。

・Mistral APIの外部公開停止：管理セグメント以外からのアクセスをセキュリティグループ／ファイアウォールで遮断する（Mistral APIの既定ポートは8989）
・WAFでの不審ペイロードブロック：APIゲートウェイ／リバースプロキシ前段で、ワークフロー登録系エンドポイントへの異常リクエストを監視・遮断
・executor隔離：Task Executorを専用VLAN／network namespaceに隔離し、不要な外向き通信を遮断（認証情報の外部送出を抑止）
・policy.yamlの監査と最小化：ワークフロー作成・公開系のルールを、より上位ロール必須に寄せる（適用前にステージングで業務影響を確認）
・低特権ロールの一時無効化：パッチ適用までの間、Mistralに到達できる不要な低特権ユーザーを一時停止する

ファイアウォール側の例として、管理セグメントのみ許可し残りを落とす形にする。

# 管理セグメントCIDRのみ8989を許可し、それ以外は遮断（例）
sudo iptables -A INPUT -p tcp --dport 8989 -s <管理セグメントCIDR> -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 8989 -j DROP

# policy.yaml の現状ルールを確認してから厳格化する
oslopolicy-policy-generator --namespace mistral 2>/dev/null | head -40

同様な認可バイパス事例

今回の「認証は通るが認可が抜けている」という型は、クラウド基盤では繰り返し現れてきた。OpenStack自身も過去にKeystoneやNovaでポリシー/トークン周りの認可不備が修正されてきたし、Kubernetesの世界でもRBACの設定不備やアドミッション制御の抜けを突く事例が後を絶たない。共通するのは、「入口の認証は厳しくしたが、各APIごとの認可チェックが網羅されていなかった」という構造だ。

教訓は明確で、認証（誰であるか）と認可（何を許すか）は別物として、エンドポイントごとに認可を検証する必要がある、という点に尽きる。Mistralのようにバックエンドで強い権限を持つコンポーネントほど、1つのエンドポイントのポリシー抜けが致命傷になる。AIエージェントやワークフロー自動化が増えるほど、「自動実行基盤が持つ認証情報」をどう守るかは普遍的な課題になっていく。

SCA/脆弱性管理

単発のパッチ適用で終わらせず、継続的に「影響バージョンが紛れ込んでいないか」を検知する仕組みを回したい。OpenStackのようにコンポーネントが多い基盤では、SCA（Software Composition Analysis）と脆弱性スキャナの併用が現実的だ。

# Trivy：コンテナイメージ／ファイルシステムのCVE検知
trivy image <mistral-image>:<tag>
trivy fs --scanners vuln /opt/stack/mistral

# Anchore（Grype）：SBOMベースのスキャン
grype dir:/opt/stack/mistral

# Red Hat 環境：Insights によるCVE判定
sudo insights-client --check-results

TrivyやGrypeはコンテナ／ソース導入のMistralに、Red Hat InsightsはRHOSP環境に向く。CI/CDに組み込み、ベースイメージ更新時に自動でCVEを検知できる状態を作っておくと、次の脆弱性公表時の初動が速くなる。

企業向けチェックリスト

OpenStackを運用する組織として、本件で最低限たどるべき項目を整理する。

・棚卸し：openstack service list／endpoint list --service workflowv2でMistral利用有無を確定したか
・バージョン：稼働中Mistralが影響版（20.1.1未満／21.0.0／22.0.0）に該当するか確認したか
・パッチ：修正版へ更新し、api/engine/executorを再起動・バージョン再確認したか
・ロール：Mistralに到達できる低特権ユーザーを棚卸しし、不要分を削除したか
・ログ：直近の作成系APIリクエストとトークン発行ログを突き合わせ、痕跡を確認したか
・隔離：executorの外向き通信とAPI公開範囲を見直し、最小化したか
・継続：SCA／脆弱性スキャンをCI/CDに組み込み、再発を検知できる状態にしたか

よくある落とし穴

実環境で対応を進める際、つまずきやすいポイントをまとめる。

・Mistralを使っている認識がない：直接APIを叩いていなくても、Heat等から内部呼び出しされている。プロセスとカタログの両方を必ず確認する
・「未認証」と誤読して対応を緩める：PR:Lは認証必須だが、敷居は低特権で足りる。外部非公開でも内部アカウント経由で成立するため、優先度は下げない
・パッチ後のpolicy.yaml互換性チェック忘れ：修正でポリシー検査が効くようになる結果、これまで通っていた低特権の作成・公開操作が拒否されることがある。ステージングで差分確認を
・リージョン間の更新タイミング差：マルチリージョン環境で一部リージョンだけ未更新のまま残ると、そこが弱点になる。更新状況をリージョン横断で台帳管理する

FAQ

よくある疑問は記事冒頭のFAQ（frontmatter）にも収録しているが、特に重要な4点を本文でも補足する。

Q. Mistralを使っていなければ無関係？ — 直接使っていなくても、Heat等から内部的に呼ばれている場合がある。サービスカタログとプロセスの両方を確認するまで「無関係」と断定しない。

Q. プライベートクラウドだから外部攻撃は不要では？ — PR:Lは「低特権の認証ユーザー1つ」で成立する。内部の一般ユーザーや漏洩したサービスアカウントが起点になりうるため、外部非公開でもパッチは必要だ。

Q. 認証情報窃取後の横展開リスクは？ — executorはNova/Neutron/Cinder/Keystone等を呼び出す認証情報を持つ。奪われると、Mistralに与えていた権限の範囲で基盤操作に及ぶ。被害は「Mistralに何を許していたか」に比例する。

Q. アップグレード版でデフォルト挙動は変わる？ — 変わりうる。ポリシー検査が効くようになるため、低特権ユーザーの一部操作がパッチ後に拒否される。自動化が特定ロールで動いている場合は、事前にロール権限を見直しておく。

参照ソース

・OSSA-2026-020: Mistral policy enforcement bypass allows unauthorized public resource creation and arbitrary code execution（oss-security、公式アドバイザリ） — 一次ソース。影響バージョン・報告者・修正ブランチはここを基準にした
・OpenStack Security Advisories（OSSA一覧、公式） — OSSA-2026-020を含む公式アドバイザリの正本
・NVD: CVE-2026-41283 — CVSS 9.9／ベクトルAV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H／CWE-863（Incorrect Authorization）の確定値
・OpenStack Mistral 公式リポジトリ — コンポーネント構成と修正反映済みのタグ／リリースの確認に使用