TITLE

AWS SSM AgentにCVSS 9.9の脆弱性、CVE-2026-89049がIMDS認証情報を漏らす仕組み

投稿日：2026.09.15

何が起きたか — 2026年9月10日の公表と対象範囲

AWSセキュリティ速報2026-107-AWSは、2026年9月10日11:30 AM PDTに公開されました。対象はリモートホストへのポートフォワーディングをサポートするSSM Agent 3.3.4851.0未満の全バージョンで、修正版は3.3.4851.0以降です。GitHub Security Advisory GHSA-w9jw-h72g-6hxcではCVSS 3.1スコア9.9(AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)、深刻度Criticalと評価されています。

この機能自体はAWSのドキュメントに説明があり、リモートホストへのポートフォワーディングにはSSM Agent 3.1.1374.0以降が必要で、転送先のリモートホストがSystems Managerの管理下にある必要はありません。RDSのエンドポイントのような、EC2インスタンス以外の宛先にもポートを転送できる汎用的な機能です。AWSとGitHub Advisoryが示す暫定的な回避策は、AWS-StartPortForwardingSessionToRemoteHostドキュメントの利用をIAM権限とSSMドキュメント権限で絞り、信頼できないプリンシパルがリモートホスト向けのポートフォワーディングセッションを開始できないようにすることです。

なぜ危ないか — 宛先が「別の顔」を持つとdenylistをすり抜ける

GitHub Security Advisoryの説明によると、このdenylistはもともとリンクローカルアドレス(IMDSを含む)へのトンネルを塞ぐ設計でした。ところが、AWSが公表した不具合の性質は"improper validation of equivalent address representations"(同一アドレスの等価な表記の検証不備)で、宛先を別の書き方で指定するとdenylistの検証をすり抜けてしまいます。修正版3.3.4851.0のリリースノートには"Canonicalize IP addresses before port-forwarding denylist check"(ポートフォワーディングのdenylistチェックの前にIPアドレスを正規化する)とあり、この記述からも、denylistが受け取った宛先の文字列をそのまま比較する作りだったことがうかがえます。

等価な別表記の宛先がdenylistをすり抜け、IMDSから一時的なIAMロール認証情報を取得してインスタンス外で使われる流れの図

denylistをすり抜けた宛先の指定がIMDSに届くと、そのマネージドインスタンスに割り当てられた一時的なIAMロール認証情報を取得できてしまいます。GitHub Advisoryが明記しているとおり、この認証情報は発行元のインスタンスを離れても有効で、インスタンスの外からAWS APIを呼び出すのに使えます。ポートフォワーディングセッション自体は内容がセッションログに記録されない種類の操作であるため、AWSのドキュメントが示すとおり、通信の中身から後追いで不正利用を検知することはできません。

今すぐやることが3つあります

1. バージョンを確認し、3.3.4851.0以降に更新する

稼働中のSSM Agentのバージョンをまず確認します。AWSのドキュメントによれば、Fleet Managerの設定で「Auto update SSM Agent」を有効にしていれば、Systems Managerが2週間ごとに新しいバージョンを確認しAWS-UpdateSSMAgentで自動更新します。State Managerの関連付けやメンテナンスウィンドウでの更新、Quick Setupの「2週間ごとに更新」オプションも同じ仕組みです。一方、Bottlerocketで動くSSM AgentはAWS-UpdateSSMAgentでは更新できず、コントロールコンテナ側での管理が必要になる点は見落としやすい例外です。

2. 暫定策として、リモートホスト向けポートフォワーディングの権限を絞る

修正版への更新が完了するまでの間は、AWSとGitHub Advisoryが共通して示す回避策を先に適用します。ssm:StartSessionのIAM権限と、AWS-StartPortForwardingSessionToRemoteHostドキュメントに対するSSMドキュメント権限を絞り、信頼できないプリンシパル(利用者やロール)がこのセッション種別を開始できないようにします。

3. CloudTrailでStartSessionの記録を確認する

CloudTrailはSystems ManagerのAPI呼び出しをすべて記録しており、StartSessionの呼び出しも管理イベントとして既定で記録されます。イベントにはリクエストパラメータ、送信元IP、日時、呼び出し主体が含まれます。StartSession APIのリクエストにはDocumentName(セッション種別を指定するSSMドキュメント名)とParameters(そのドキュメントへのパラメータ値)が含まれるため、次のように過去のイベントを絞り込めます。

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=StartSession

出力の中からリクエストパラメータのドキュメント名がAWS-StartPortForwardingSessionToRemoteHostのものを探し、パラメータのhostにリンクローカル表記(169.254.x.x など)や見慣れない表記が混じっていないかを確認します。CloudTrailのイベント履歴は各リージョンで直近90日分に限られるため、それより前まで遡って確認したい場合はトレイルかCloudTrail Lakeの記録が必要です。なお、IMDSv2(トークン必須化)がこのSSRFに対する防御になるかどうかは、AWSの一次情報からは確認できていません。

気づき — 修正は公表の2カ月前に出ていました

封蝋で固定された木箱のイラスト。AMIに焼き込まれて更新されないバージョンを表す

GitHubのリリース履歴を確認すると、修正版3.3.4851.0が公開されたのは2026年7月13日です。前後のリリースは3.3.4624.0(6月2日)、3.3.4793.0(6月24日)、そして3.3.4851.0の後に3.3.5068.0(8月5日)、3.3.5226.0(8月20日)と続いています。AWSが脆弱性を公表したのは9月10日なので、修正そのものは公表より2カ月近く前に、リリースノート上はCVE番号への言及がないまま配布されていたことになります。

この2カ月の空白は、SSM Agentの管理方式によって明暗を分けます。自動更新を有効にしている環境は、Systems Managerが2週間ごとにバージョンを確認する仕組みのおかげで、公表を待たずに3.3.4851.0以降へ既に更新されていた可能性が高い環境です。一方、Amazon Machine Image(AMI)に焼き込まれたSSM Agentのバージョンに頼る環境は、AMI自体が更新されない限り古いバージョンのまま残ります。実際、awslabs/amazon-eks-ami issue #2817によれば、2026年9月14日時点で最新のEKS最適化AMI(v20260903)に含まれるamazon-ssm-agentは3.3.4624.0で、修正版に達していません。このissueは起票された時点でメンテナからの回答がついていませんでした。

「公表されてから対応する」運用は、この事例では本質的に後手です。自動更新の仕組みが機能していれば、公表日を待たずに守られていた可能性が高い一方、AMIという「焼き付けられた版」に依存する構成は、AMI自体の更新を追いかけない限り取り残されます。

まとめ

CVE-2026-89049そのものへの対策はバージョン確認・権限の絞り込み・CloudTrailの確認という3点に尽きますが、今回分かった「修正は公表の2カ月前から存在していた」という事実は、更新経路の設計そのものを見直す材料になります。自動更新に任せられる部分は任せ、AMIに焼き込む部分は更新の仕組みを別に持つ、という役割分担です。次に同種のアドバイザリが出たときに効くのは、公表を見てからSSM Agentのバージョンを洗い出すことではなく、どの環境がどちらの経路で管理されているかを、今のうちに一覧にしておくことです。