AWS SAM CLIのTerraformフックに脆弱性｜OSコマンドインジェクション CVE-2026-115414

AWSは2026年10月22日、サーバーレス開発ツールAWS SAM CLI（aws-sam-cli・Apache-2.0）のOSコマンドインジェクション脆弱性 CVE-2026-115414 を公表した。sam build --hook-name terraform が生成するMakefileに、Terraformのリソースアドレスがシェルのメタ文字を十分中和せずに補間される。ビルドが読む設定やplanに影響できる者が、ビルドホスト上でビルドユーザーの権限で任意コマンドを実行できる。本記事は公式Bulletinと公開アドバイザリ、修正版と脆弱版のソースを突き合わせて、影響の境界と確認手順を整理する。武器化手順（PoC）は載せない。

この脆弱性はサプライチェーンの観点でも読める。全体像はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめている。

経緯｜公表から修正まで

AWS SAM CLIは、サーバーレスアプリをローカルでビルド・テスト・デプロイするための公式CLIである。Terraformで管理したLambda関数を扱うために、sam build・sam local invoke などにTerraformフック（--hook-name terraform）が用意されている。このフックの経路に今回の問題があった。

本記事の執筆時点（2026-10-27）で、aws/aws-sam-cli のタグには v1.166.1 と修正版 v1.166.2 がともに存在し、最新タグは v1.170.0 であることを git ls-remote --tags で確認した。修正コミットの正確な公開日や、悪用の有無についての断定は、公式が明言した範囲を超えるため行わない。既知の悪用報告は無いとされる。

ビルド・パイプラインの文脈で任意コード実行につながる脆弱性は珍しくない。たとえばGitHub RCE脆弱性CVE-2026-3854解説：git push一発でサーバー乗っ取り、Wizが発見は、パイプライン側の処理が攻撃者の入力を実行してしまう類例である。

何が起きたか｜リソースアドレスがMakefileのレシピに通る

Terraformフックを使う sam build は、内部でLambdaリソースごとにMakefileのビルドルールを生成する。脆弱版（v1.166.1）では、このレシピにTerraformのリソースアドレスと、そこから作る検索式（jpath）を文字列として埋め込んでいた。

埋め込みのときにエスケープしていたのは"（ダブルクオート）を\"に置き換えるところだけで、$()・バッククォート・;・&&・| といったシェルのメタ文字はそのまま残る。生成されたレシピは make がマクロ展開したうえでシェル（Linux/macOSは /bin/sh、Windowsで sh.exe が無ければ cmd.exe）に渡される。したがって、リソースアドレスにメタ文字を仕込めれば、それがシェルに解釈されて任意コマンドになる。

ここでのリソースアドレスは、ビルドが読むTerraformの設定やplanに由来する（SAM CLIがメタデータリソースの address を取り出して使う）。つまり「ビルドが読むTerraform設定・planに影響できる者」が注入の起点になる。修正版のソースコードにも「make のマクロ展開に対しても、両方のシェルに対しても同時に安全な単一のエスケープ方式は存在しない」と明記されている。これが、エスケープで塞ぐのではなく後述の方法で直した理由である。

対策｜v1.166.2以降へ更新し、設定とplanの出所を限る

恒久対策は更新である。更新までの緩和策は、注入の起点（未信頼の設定・plan・module）を断つことになる。

第三者が自動で送るPRや依存更新が実行経路に乗る問題は、Renovate・Dependabotの自動PRがマルウェアを運ぶ：違いの比較と今すぐ確認すべき安全設定でも扱っている。出所の管理という点で発想は近い。

修正版（v1.166.2）は、エスケープを強化するのではなく、未信頼の文字列をレシピから外した。リソースアドレスと検索式を .args.json ファイルに書き出し、ビルドスクリプトがそのファイルをディスクから直接読む。Makefileのレシピに乗るのは安全なファイルパスだけになり、シェルに未信頼の文字列が渡らない。注入の経路そのものを無くす直し方である。

自分の環境を確認する｜版とTerraformフックの利用

次の確認は「影響しうる構成か」を見るためのもので、侵害されたかどうかの判定ではない。侵害の確認にはビルドログやCIの実行履歴の監査が別に要る。

まず、使っている sam の版を確認する。1.63.0以上かつ1.166.1以下なら影響版である。

sam --version

パッケージマネージャ経由で入れている場合は、こちらでも版を確認できる（入っていない経路は何も表示しない）。

pip show aws-sam-cli 2>/dev/null | grep -i '^Version:'
brew list --versions aws-sam-cli 2>/dev/null
pipx list 2>/dev/null | grep -i aws-sam-cli

次に、Terraformフックを使っているかをリポジトリ内で確認する。CIスクリプトやMakefileに --hook-name terraform が無いかを探す。

grep -rnE -- '--hook-name[ =]terraform' . 2>/dev/null

影響範囲｜誰が、何を前提に影響を受けるか

この脆弱性は前提の取り違えで評価がぶれる。リモート未認証のRCEではなく、ビルド時に未信頼のTerraform入力を読むときに限って成立する。

攻撃者が何に影響でき、その結果何ができるかを分けると次のようになる。

逆に、影響しない（または前提が外れる）のは、v1.166.2以降に更新済み／Terraformフックを使わない sam build／設定・plan・moduleの出所がすべて自組織管理で信頼できる場合である。奪われる権限は「ビルドを走らせているユーザー」のものなので、CIランナーがクラウドの一時認証情報を持っていれば被害はビルドホストの外にも及びうる。CIの実行権限やシークレットが起点になる攻撃の流れはAIコーディングエージェント 脆弱性｜GitHub Issue起点でCI/CDシークレットが漏れる攻撃チェーンでも整理した。ここは構成しだいで、公式が一律に断定している範囲ではない。

まとめ

リモート未認証の派手な脆弱性ではないが、CIの中で静かに任意コマンドが走る経路である。前提（誰がTerraform入力に影響できるか）を自分の構成で確かめ、更新と出所の管理の両方で塞ぐのがよい。

参照ソース

・AWS Security Bulletin 2026-145-aws — CVE-2026-115414の一次情報（2026-10-22公表・2026-10-27参照）
・GitHub Advisory GHSA-44mq-wjrh-vpj6 — 影響版・修正版・CVSS・CWE（2026-10-27参照）
・aws/aws-sam-cli（公式リポジトリ・タグ） — v1.166.1・v1.166.2・最新 v1.170.0 を git ls-remote で実測（2026-10-27）