AWS SAM CLIのTerraformフックにコマンド注入｜失敗したビルドも調査対象に

AWS SAM CLIでsam build --hook-name terraformを使っているチームは、開発端末とCIの実行版を確認してください。Terraformの設定やplanファイルへ影響を与えられる攻撃者が、ビルドを動かす利用者の権限でOSコマンドを実行できる脆弱性CVE-2026-115414が公表されています。修正版は1.166.2です。

AWS：SAM CLIのTerraformフックに関するセキュリティ告知は10月22日11時30分PDT、日本時間10月23日3時30分の公表です。本稿は10月25日に資料を確認しました。主な対象はサーバーレスアプリをビルドする開発者・CIの運用担当者で、公開中のLambda関数だけを更新して完了する問題ではありません。

対象版と攻撃の入口

対象はAWS SAM CLI 1.63.0以上、1.166.2未満です。AWS SAM CLI開発元：GHSA-44mq-wjrh-vpj6によるCVSS v3.1は7.8、High。TerraformフックがSAMメタデータのリソースアドレスからビルド指示を生成する際、シェルで特別な意味を持つ文字を十分に無害化しないことが原因です。

攻撃の成立には、ビルドで使用されるTerraformの設定またはplanファイルへ攻撃者が影響できる条件があります。インターネットから任意のLambda関数を直接攻撃できるという説明ではありません。コードレビュー前の変更、第三者モジュール、共有リポジトリーから取り込む入力が、このビルドへ届くかを点検します。

設定ファイルが実行権限へ届く経路を見つける

今回の確認では、Terraformを使っているかだけで対象を決めず、その設定やplanがSAM CLIのTerraformフックへ渡るかを追います。AWS告知が対象としているのは、このビルド処理へ到達する入力です。Terraformを使うすべてのシステムや、SAM CLIのすべてのコマンドを同じ条件で扱うと、必要な対応箇所を見失いやすくなります。

本サイトは、入力を作る処理と、それをビルドする処理を一組で確認することを勧めます。設定を編集できる人、planを生成した実行、受け渡す成果物、ビルド側が選んだ版を順に記録します。リポジトリー自体は社内管理でも、外部の変更や共有成果物を取り込む経路があれば、その部分も確認対象です。

例えば、外部からのプルリクエストを検証するジョブが設定を取り込み、後続のジョブがその成果物を使ってTerraformフックを実行する構成を考えます。これは仮想例です。後続ジョブの定義が保護されていても、未承認の入力を処理しているなら、ジョブの定義だけをレビューして安全とは判断できません。

コードの変更者とビルドを開始する人が違う場合にも注意します。攻撃者自身が開発端末やランナーへログインできなくても、利用者が処理する入力へ影響できるかが重要です。一方、レビューを経ていない設定が存在するだけで直ちに侵害が起きるわけではありません。対象版のフックで実際に処理したかまで区別します。

AWS資格情報がなくても実行される

開発元は、コマンドの実行にAWS資格情報は不要で、ビルドがその後に失敗しても実行され得ると説明しています。ビルド環境の秘密情報へのアクセスや、成果物の改変につながる可能性があります。「デプロイしていない」「ビルドが赤くなった」だけで影響なしとは判断できません。

AWSの認証に成功するかどうかと、端末やランナー上でOSコマンドが動くかは別の境界です。本サイトでは、AWSキーの有無だけで対象を絞らず、そのジョブが参照できる他のCI用トークン、署名鍵、作業ディレクトリー、共有成果物も確認することを勧めます。これは調査の観点であり、今回それらが実際に窃取されたという報告ではありません。

まず更新しビルド入力の信頼範囲を確認する

AWSはAWS SAM CLI：修正版1.166.2以降への更新と、フォーク・派生コードへの修正取り込みを推奨しています。更新までの対応として、設定ファイルとplanファイルの出所を信頼できるものに限定し、第三者モジュールや共有リポジトリーを監査するよう案内しています。入力の制限を、修正版への更新の代わりに放置しないでください。

以下は本サイトが勧める確認順序です。自社環境での再現実験は行っていません。

• ワークフローと開発手順からTerraformフックの利用箇所を探し、設定・planファイルの作成元と変更可能な人を確認する。
• 実際にビルドする端末・ランナー・コンテナのSAM CLIを修正済みの版へ更新する。導入元の設定や固定版も変更し、次回実行で古い版に戻らないことを確認する。
• ビルド開始時の実行版を記録し、承認した入力で通常のビルドができることを検証する。設定ファイル上の番号だけで完了にしない。
• 更新前に未信頼の入力を処理していた場合は、失敗した実行も含めてログ、入力の版、成果物の由来を調べる。不審な操作があれば、実際に参照可能だった資格情報とその利用履歴を確認する。

GitHub Docs：ワークフローの安全な利用も、未信頼のコードを特権のあるワークフローで処理する危険と、トークンの最小権限を説明しています。SAM CLIを直す対応と、検査ジョブへ本番の権限を渡しすぎない設計を分けて管理すると、同様の問題が起きた際の影響を限定しやすくなります。

実行版の確認は端末とランナーごとに行う

本サイトは、開発者の端末、CIの実行イメージ、再利用されるビルド環境を別々に洗い出すことを勧めます。ワークフローの導入手順を更新しても、古いコンテナイメージや、別の場所へ入った実行ファイルが使われる場合があります。設定ファイルに書かれた版と、実行時に選ばれた版を同一視しないことが更新確認の要点です。

版の確認例は次のとおりです。ビルドする環境と同じユーザー・同じ実行経路で確認します。この操作は版の表示であり、今回の脆弱性を再現するものではありません。利用者の端末やCIで本サイトが検証した結果ではないため、出力を自分の実行環境の記録として残してください。

sam --version

CIでは、版を表示したステップとビルドのステップが同じ環境を使うかも確認します。前のステップでホスト側の版を確認し、実際のビルドは別コンテナで動かしていた、という取り違えを防ぐためです。出力された版を実行IDやイメージの識別情報と結び付けておけば、後からどの実行が更新前だったかを調べやすくなります。

更新後は、承認済みの設定とplanを使って通常のビルドができることを確認します。攻撃用の入力を本番ランナーへ流して、修正できたかを試す必要はありません。フォークや社内配布版を使う場合は、表示上の版番号だけでなく、修正が取り込まれたことを配布元の変更履歴で確認してください。

失敗した実行も含めて過去の影響を調べる

調査の起点は、未信頼の設定やplanを対象版で処理した実行です。本サイトは、ビルドの成否で候補を落とさず、実行日時、入力のコミットや成果物、実行ユーザー、処理した環境を対応付けることを提案します。正常にデプロイされていない場合でも、ビルド中に動いた処理の有無は別に確認します。

まず関連するログと入力の版を保全し、ビルドの指示やその実行記録に想定外の処理がないかを確認します。ログに不審な行がないことだけで、コマンド実行がなかったと証明できるとは限りません。保存されている情報と、当時記録していなかった情報を区別し、判断の根拠を残します。

次に、その実行ユーザーが読めた情報と書き換えられた場所を調べます。CIのトークンが環境変数で渡されていたか、作業ディレクトリーに資格情報や署名用ファイルがあったか、後続工程が使う成果物を変更できたか、といった範囲です。これらは今回の事件で漏えいが確認された項目ではなく、自社の権限から影響範囲を決めるための確認点です。

不審な処理が確認できた場合は、セキュリティ担当者と連携し、実際に参照可能だった資格情報の失効・再発行や利用履歴の調査を判断します。脆弱な版があったという理由だけで、無関係な資格情報まですべて漏えいしたとは扱いません。証拠の保全と封じ込めを並行して進め、調査前の削除や再実行で記録を失わないようにします。

成果物に改変の疑いがあれば、その実行から作られた配布物を後続工程へ渡さず、信頼できる入力と修正済みの環境から作り直すことを検討します。ビルドの更新、資格情報の対応、成果物の扱いは、それぞれ別の完了条件です。CLIを更新しただけで、過去に出力されたファイルまで安全になったとは判断できません。

ビルドとデプロイの権限を分けて被害を限定する

GitHubの安全な利用の資料は、未信頼のコードを特権のあるワークフローでチェックアウトする危険を説明しています。GitHub Actionsを使う場合は、イベントの種類だけを見て安全と決めず、どの版を取得し、どの成果物を実行し、その時点でどのトークンや秘密情報へ届くかを確認します。

今回の脆弱性への優先対応はSAM CLIの更新です。そのうえで本サイトは、設定の検査やビルドに不要な本番権限を渡していないかを見直すことを勧めます。承認前の入力を扱う工程が、デプロイ用の秘密情報や書き込み権限へ届かなければ、ビルド処理に問題が生じたときの影響を抑えやすくなります。

承認を設けている場合は、承認した入力と実際にビルドへ渡した入力が一致するかも確認します。別の実行が作ったplanや成果物へ後から差し替わる経路があると、設定をレビューしたという事実だけでは十分ではありません。入力の識別情報と実行IDを対応付ける記録を残すと、この確認に役立ちます。

更新完了と過去の影響確認を分ける

修正版へ更新できたことは、過去のビルドが安全だった証明にはなりません。一方、脆弱な版を使っていたという事実だけで侵害が起きたとも断定できません。今回確認した提供元の告知は実環境での悪用を報告していません。入力を変更できた範囲と実行記録を基に、自社で追加調査が必要か判断してください。

関連する権限設計は、GitHub Actionsで本番権限を守るレビュー手順に整理しています。同記事は一般的なCIの防御を扱う解説です。今回の脆弱性固有の対象版と修正境界は、本稿のAWS告知を基準にしてください。