REXの導入例にコマンド注入の脆弱性 作成済みSSMドキュメントの削除が必要

AWSは2026年11月6日、Trusted Remote Execution（REX）の導入ガイドに掲載されていた例から作成したSSMドキュメントに、OSコマンドインジェクションの脆弱性があると公表しました。対象はRex-ROとRex-RWを作成した環境です。利用したアカウントとリージョンを洗い出し、該当ドキュメントを削除する必要があります。REX本体の更新だけで対応を完了できる問題ではありません。

本記事は11月7日に確認した脆弱性ニュースと対応の解説です。AWS告知の公表時刻は11月6日9時PST、日本時間では11月7日2時です。以下では提供元が求める削除と、本サイトが提案する棚卸し・業務影響の確認を区別します。コマンド例は手順の説明用で、読者のAWS環境での実行結果ではありません。

対象はREX本体の版ではなく導入時に作った実行口

AWS セキュリティ告知2026-173-AWSによると、REXは管理対象インスタンス上でスクリプトを隔離して実行するオープンソースの仕組みです。各実行の境界には署名付きCedarポリシーを使う設計ですが、問題の導入例では、その前段にあるSSMドキュメントの入力処理に不備がありました。scriptArgsパラメーターも同じ種類の問題の対象です。

CVE Program CVE-2026-122193公式レコードではCVE-2026-122193として公開され、認証済みの遠隔利用者がRex-ROまたはRex-RWを呼び出す権限を持つ場合、管理対象インスタンスでrootとして任意コマンドを実行し、Cedarの制御を回避し得ると説明されています。認証不要で誰でも攻撃できるという条件ではありません。

同レコードは2026年7月28日より前の導入例に言及しています。一方、AWSの対処指示はガイドに従って作ったドキュメントの削除です。作成日だけを手掛かりに対象外とせず、どの例を使い、何が実際に作られたかを確認するのが確実です。既存構成を調べずに「新しいREXを入れたから安全」と判断しないでください。

REX開発元 GHSA-95g5-m242-wvhrのパッケージ欄には影響版・修正版とも0.1.0と表示されますが、本文は配布済みREX成果物の版の問題ではなく、適用するコードパッチはないと明記しています。AWSは導入例を削除済みで、既に作ったSSMドキュメントは利用者側で削除するよう勧めています。回避策も「なし」です。

深刻度と実環境の悪用を分けて判断する

開発元の評価はCVSS v3.1で9.9、Criticalです。公式CVEレコードにはv4.0の9.3も併記されています。本記事で9.9と示す場合はv3.1の値です。点数の違いを修正の進展や危険度の低下と読み替えず、評価方式をそろえて判断します。

確認したAWS告知と開発元勧告には、実環境での被害や悪用を確認したとの記載はありません。これは悪用が存在しないという証明ではありません。今回の優先順位は、被害報道を待つことではなく、対象の実行口が残っているか、誰が呼び出せるかを確かめることに置きます。

最初にアカウントとリージョンの確認表を作る

以下は本サイトの運用上の提案です。REXを試した担当者、導入手順を管理するリポジトリ、検証環境の記録から、例を実行したアカウントとリージョンを列挙します。本番担当だけに聞くと、検証用や別部署の環境が抜けることがあります。導入経験が不明な環境も、未確認として表に残します。

AWS CLI list-documentsは現在のアカウントとリージョン内のSSMドキュメントを返します。一度の一覧取得で組織全体や別リージョンまで確認したことにはなりません。通常はページ分割をCLIが処理しますが、--no-paginateなどで結果を途中までに制限していないかも確認してください。

確認表には、アカウントID、リージョン、Rex-ROの有無、Rex-RWの有無、導入例との対応、利用中のジョブ、対応担当、確認時刻を記録します。「ない」と「権限不足で見えない」は分けてください。アクセス拒否や接続失敗を対象なしに丸めると、未確認の領域が対応済みとして残ります。

名前が一致した場合は、所有者や作成経緯を確認し、問題の例から作ったものかを追います。独自に改名したり、テンプレートへコピーしたりしていないかは、手順や構成管理側でも検索します。ただし同じような名前の無関係な文書を、内容を確認せず一括削除する手順にはしません。

読み取りで内容と参照元を確認してから削除する

AWS CLI describe-documentは指定したSSMドキュメントの情報、AWS CLI get-documentは内容を取得するためのコマンドです。調査用と削除用の作業を分け、まず正しい接続先であることと文書の内容を確認します。次は東京リージョンを例とした読み取りで、example-profileは実際に確認する接続設定へ置き換えます。

aws ssm describe-document --name Rex-RO \
  --profile example-profile --region ap-northeast-1
aws ssm get-document --name Rex-RO \
  --profile example-profile --region ap-northeast-1
aws ssm describe-document --name Rex-RW \
  --profile example-profile --region ap-northeast-1

この例をそのまま他環境への自動処理に拡張せず、まず一組のアカウントとリージョンで結果の読み方を確認します。Rex-RWについて内容の確認が必要なら、同じ接続先を明示してget-documentを使います。取得した文書には運用情報が含まれ得るため、調査結果の共有先と保管場所も管理します。

併せて、該当文書を参照する運用ジョブや導入スクリプトの担当者を確認します。削除により既存の実行手順が利用できなくなる場合に備え、停止する作業と代替手段を決めるためです。これは削除を先延ばしする根拠ではなく、危険な例を残さず業務の切り替えを進めるための確認です。

公式の対処は作成済みSSMドキュメントの削除

コンソールでの削除は、AWS カスタムSSMドキュメントの削除にあるとおり、Systems ManagerのDocumentsで対象を選び、Deleteと確認操作を行います。アカウントとリージョンを切り替えて作業する場合は、対象名だけでなく現在の接続先も毎回確認してください。

AWS CLI delete-documentは、削除前に関連付けられた管理対象ノードをDeleteAssociationで関連解除することを推奨しています。また、バージョンを指定しない削除は全バージョンが対象です。関連付けの有無と運用への影響を確認し、一部の版だけを消して問題の文書が残ることを避けます。

aws ssm delete-document --name Rex-RO \
  --profile example-profile --region ap-northeast-1
aws ssm delete-document --name Rex-RW \
  --profile example-profile --region ap-northeast-1

これは、導入例から作成した対象だと確認した後に行う削除の例です。実行前に担当者が対象をレビューし、必要な調査記録を確保します。削除対象をワイルドカードで広げたり、理由が分からないエラーに対して--forceを追加したりする運用は避け、公式仕様と実際の関連付けを調べます。

削除コマンドは正常時も出力がありません。画面に何も表示されないことだけで完了とせず、コマンドの終了状態を確認し、同じプロファイルとリージョンで一覧やdescribe-documentを読み戻します。削除が失敗した場合は、その環境を未完了として残し、権限や関連付けの問題を解決します。

削除後は再作成の経路と過去の利用を点検する

削除後の本サイトの提案は、古い導入例を再実行しない仕組みまで確認することです。構成管理、社内の導入メモ、初期設定ジョブに同じ作成処理が残っていれば、次の環境構築で戻る可能性があります。既存文書の削除と作成元の是正を、別の完了項目として扱います。

また、削除が過去の不正実行の有無を証明するわけではありません。利用可能な監査記録やジョブの履歴を用いて、誰がいつ対象文書を使ったかを調べることを勧めます。記録がなければ「悪用なし」とは判断せず、保存期間や収集範囲の限界を明示して調査担当へ引き継ぎます。

不審な利用が見つかった場合は、文書を呼んだ主体と対象インスタンスを対応付け、既存のインシデント対応手順で影響を調べます。公式資料には、すべての環境へ共通に適用できる侵害判定のログ文字列や復旧手順は示されていません。特定の記録がないことだけを安全の根拠にしないことが重要です。

完了報告では、削除した文書と接続先、削除後の確認結果、古い作成処理の扱い、調査を継続する範囲を分けて示します。対象なしと確認できた環境にも、確認者と時刻を付けます。全アカウント・リージョンの確認が終わるまでは、一つの成功を全体の対応完了へ広げないようにします。

今回の判断は導入資産が残っているかで決まる

REXを使うチームは、本体の依存関係一覧に加えて、導入手順から生成された運用資産を把握する必要があります。本件で優先するのは、Rex-ROとRex-RWの作成履歴を確認し、該当する実行口を取り除くことです。独自の入力加工だけで公式の対処を置き換えず、対象環境ごとの削除確認まで進めてください。

関連記事

入力をコマンドに渡す境界の設計は、既存の実践解説「コマンドインジェクションを防ぐ実装」で扱っています。今回の対象文書の削除を代替する手順ではありません。