AWS SSM Agent脆弱性(CVE-2026-89049)の検知と実務的リスク評価

2026年9月10日に公開されたAWS Systems Manager Agent（SSM Agent）の脆弱性「CVE-2026-89049」は、CVSS v3.1スコア9.9という極めて高い数値を叩き出し、セキュリティ界隈を一時的に騒然とさせました。しかし、現場のシニアエンジニアとして冷静に分析すると、このスコアが示す「Critical」というラベルと、実際の攻撃シナリオにおける脅威度には、少なからぬ乖離があると言わざるを得ません。本脆弱性は、SSM Agentのバージョン3.3.4851.0未満において、Session Managerのポートフォワーディング機能にSSRF（Server-Side Request Forgery）の欠陥が存在するというものです。具体的には、EC2からRDSへの接続を想定したポートフォワーディング機能が悪用され、本来EC2へのアクセス権限を持たないユーザーが、EC2の一時的なIAMクレデンシャルを不正に取得できてしまうというシナリオです。

ここで我々が直面する技術的な問いは、「この脆弱性が本当に組織のインフラを崩壊させるトリガーになるのか」という点です。結論から言えば、既にEC2へのSSMアクセス権限やRun Command実行権限が付与されている環境においては、この脆弱性の有無に関わらず、攻撃者は同様のクレデンシャル取得が可能です。つまり、この脆弱性が真に脅威となるのは、極めて限定的な「ポートフォワーディング機能のみを許可し、EC2本体への直接的な操作権限を厳格に制限している」という、高度にセグメント化された環境に限られます。多くの現場では、利便性を優先して広範な権限を付与しているケースが散見されますが、そうした環境ではこの脆弱性は「既に開いている扉」をわざわざノックするようなものに過ぎません。我々エンジニアは、CVSSのスコアという抽象的な指標に踊らされるのではなく、自社のIAMポリシーがどのような境界線を描いているのか、その「実効的な権限」を今一度精査すべきです。

では、実際にこの脆弱性が悪用された形跡をどう特定するか。AWSコンソールのEvent Historyから手動で検索するのは、数千、数万のログが流れる本番環境では現実的ではありません。我々が取るべきアプローチは、AWS CLIを用いたフィルタリングと、CloudTrailのイベントログの構造を理解した上でのクエリ実行です。具体的には、AWS-StartPortForwardingSessionToRemoteHostというドキュメント名に注目し、そのパラメータ内のhostフィールドを精査する必要があります。ここに169.254.169.254といったIMDS（Instance Metadata Service）へのアクセスを試みる文字列が含まれていれば、それは攻撃の明確なシグナルです。特筆すべきは、この攻撃がIMDS v1だけでなく、v2環境下でも成立し得るという点です。これは、SSRFの脆弱性がメタデータサービスという「クラウドの心臓部」を直接狙い撃ちにする性質を持っているためです。

以下に、実務で活用可能な調査用のCLIコマンドのロジックを整理します。このスクリプトは、特定の期間におけるポートフォワーディングセッションを抽出し、パラメータを解析するものです。

この調査において重要なのは、単にログを抽出するだけでなく、jqコマンドを駆使してprincipalArnやsourceIPAddressを紐付け、誰が、どのIPから、どのターゲットに対して通信を試みたのかを相関分析することです。もし、本来の業務フローから逸脱したポートフォワーディングの試行が見つかった場合、それは単なる設定ミスではなく、侵害の初期段階（Initial Access）である可能性を疑うべきです。深夜の障害対応で疲弊している時に、こうしたログの海から異常値を見つけ出すのは至難の業ですが、日頃からInfrastructure as Code（IaC）でIAMポリシーを管理し、最小権限の原則を徹底しているチームであれば、こうした「ノイズ」を最小化できているはずです。結局のところ、セキュリティ対策とはツールを入れることではなく、ログを読み解くための「コンテキスト」をどれだけ日頃から構築できているかに帰結するのです。

今回のCVE-2026-89049を通じて我々が学ぶべき教訓は、脆弱性管理の「優先順位付け」の難しさです。CVSS 9.9という数字は確かにインパクトがありますが、それが自社のアーキテクチャにおいてどのような攻撃ベクトルを許容するのかを理解しなければ、無駄なパッチ適用に追われることになります。SSM Agentのアップデートは当然の義務ですが、それ以上に重要なのは、ポートフォワーディングの権限を誰に、どのような条件で与えているかという「ガバナンスの再定義」です。もし、あなたの組織で「とりあえずフルアクセス」のようなIAMポリシーが放置されているなら、今回の脆弱性対応は対症療法に過ぎません。明日から取り組むべきは、SSMのドキュメント単位での権限制御（ABACやABACの活用）の導入であり、CloudTrail Lakeを用いた継続的なモニタリング体制の構築です。

最後に、読者であるエンジニアの皆さんに問いかけたい。あなたは、自社のクラウド環境で「どのユーザーが、どのセッションで、どのリソースにアクセスしているか」を、ログを見ずとも即座に説明できるでしょうか。脆弱性は常に発生し、パッチは常に遅れてやってきます。我々が守るべきは、特定の脆弱性に対するパッチの適用速度ではなく、脆弱性が悪用されたとしても「被害を最小限に抑え込める」という強固なアーキテクチャの設計思想です。この脆弱性を単なる「アップデート案件」として処理して終わらせるのか、それとも自社のIAM設計を見直す契機とするのか。その選択が、半年後のあなたのインフラの堅牢性を決定づけるのです。今すぐ、CloudTrailのログを叩き、自社の環境が「攻撃者にとってどれほど居心地が悪い場所か」を確認することから始めてください。