AWSは2026年9月10日、AWS Systems Manager Agent（SSM Agent）のSSRF脆弱性 CVE-2026-89049 に関するセキュリティ速報を公開しました。
悪用されると、ポート転送の宛先制限（denylist）を回避してリンクローカルアドレスに到達され、そのインスタンスに割り当てられた一時的なIAMロール認証情報を、インスタンスの外から取得・使用されるおそれがあります。第三者による評価ではCVSS v3.1で9.9とされています。
修正版は3.3.4851.0で、リリース自体は2026年7月13日に済んでいます。つまり「もう直っているが、自社のエージェントが上がっているかは別問題」というタイプの脆弱性です。ここが今回の肝です。
この記事でわかること
- SSM Agentとは何で、なぜ「入れた覚えがなくても動いている」のか
- CVE-2026-89049で具体的に何を取られるのか
- すぐにできる緩和策（IAM権限のスコープ絞り）
- 自社が影響を受けたかを確認する方向性
SSM Agentとは何者か（EC2を使っているなら、ほぼ関係がある）
SSM Agentとは、EC2インスタンスやオンプレミスのサーバをAWS Systems Managerから遠隔管理するための常駐エージェントです。サーバ内で動き、AWS側からの指示を受けて処理を実行します。
主な使われ方は次のとおりです。
- Session Manager：SSHの鍵や踏み台サーバなしでシェル接続する
- Run Command：複数台へまとめてコマンドを実行する
- Patch Manager：OSのパッチ適用を管理する
- ポート転送：インスタンス経由で、その先のホストへポートを転送する（今回問題になった機能）
重要なのは、SSM AgentはAWSが提供する公式AMIの多くにあらかじめ導入されているという点です。「自分でインストールした覚えがない」サーバでも動いている可能性が高く、「うちはSystems Managerを使っていない」はエージェントが入っていない根拠になりません。どのAMIに含まれるかはAWS公式ドキュメントで確認できますが、実務的にはSystems Managerのフリートマネージャーで管理対象インスタンスとエージェントのバージョンを一覧するのが早い確認方法です。
何が起きるのか
問題があったのは、リモートホストへのポート転送機能（SSMドキュメント AWS-StartPortForwardingSessionToRemoteHost）です。
この機能には、転送先としてリンクローカルアドレスなど危険な宛先を拒否する仕組みがありました。しかし同じアドレスを別の表記で書いた場合の検証が不十分で、拒否リストをすり抜けられます。その結果、次のことが起こりえます。
- ポート転送の権限を持つ認証済みユーザーが、細工した宛先ホスト値を指定する
- 拒否リストを回避してリンクローカルのエンドポイント（インスタンスメタデータ）へ到達する
- そのインスタンスのIAMロールの一時認証情報を取得する
- 取得した認証情報を使い、インスタンスの外からそのロールの権限で操作する
ここが怖いところです。AWSではインスタンスに紐づくIAMロールを通じてS3やRDSなどへアクセスさせる設計が一般的です。そのロールの権限がそのまま持ち出されるため、影響範囲は当該サーバ1台では収まりません。
「認証済みユーザー」が必要なのに、なぜ深刻なのか？
この脆弱性は未認証で誰でも突けるものではなく、ポート転送の権限を持つ認証済みユーザーが前提です。にもかかわらず深刻とされる理由は、権限の境界を越えられる点にあります。
「限定的な作業をさせるために、ポート転送だけ許可した委託先や開発メンバー」が、そのインスタンスのロール権限一式に化けるということです。最小権限の原則で組んだつもりの設計が、この1点で崩れます。
影響と修正バージョン
| 項目 | 内容 |
|---|---|
| CVE | CVE-2026-89049 |
| 影響を受けるバージョン | 3.3.4851.0 より前（リモートホストへのポート転送に対応する全バージョン） |
| 修正バージョン | 3.3.4851.0（2026年7月13日リリース） |
| 速報公開日 | 2026年9月10日 |
| CVSS | 第三者評価でv3.1 9.9／v4.0 8.5（AWS公式速報にはスコアの記載なし） |
なおAWS公式の速報にCVSSスコアの記載はありません。本記事に載せた数値は第三者データベース等による評価です。社内報告でスコアを使う場合は、この出所の違いを添えておくと後で揉めません。
いますぐやること
1. エージェントのバージョンを確認して更新する
Systems Managerのフリートマネージャーで、管理対象インスタンスのSSM Agentバージョンを一覧できます。3.3.4851.0 未満が残っていないかを確認してください。SSM Agentの自動更新を有効にしている環境では、すでに更新済みの可能性があります。裏を返すと、自動更新を切っている環境ほど残っているということです。
2. 更新できるまではIAMでスコープを絞る
AWSは緩和策として、AWS-StartPortForwardingSessionToRemoteHost ドキュメントの利用を、ssm:StartSession のIAM権限とドキュメント権限で制限することを挙げています。信頼できない主体がリモートホストへのポート転送セッションを開始できない状態にする、という考え方です。
ここは更新後も見直す価値があります。そもそもリモートホストへのポート転送を必要としている利用者はどれだけいるのかを棚卸しすれば、恒久的に攻撃面を減らせます。
3. 過去の利用状況を振り返る
CloudTrailには StartSession のイベントが記録されます。いつ・誰が・どのSSMドキュメントでセッションを開始したかを確認すれば、リモートホストへのポート転送が実際に使われていたかどうかの当たりが付けられます。使われた形跡がある場合は、当該インスタンスのIAMロールで想定外のAPI呼び出しが起きていないかまで追ってください。
クラウドの一時認証情報をめぐる論点は、AWSの認証後セッションを再評価｜査読前研究解説でも扱っています。「認証を通した後のセッションをどう疑うか」という話は、今回の構図とそのまま重なります。
現場目線の課題：もう直っている脆弱性ほど残りやすい
この件で厄介なのは、修正が7月13日に出ていて、脆弱性の公表が9月10日という順番です。
普段の運用だと、脆弱性が公表されて初めて「うちは大丈夫か」と動き出します。ところが今回は、公表より2カ月前にすでに修正版が配られていた。自動更新が効いている環境は何もしなくても直っていて、自動更新を止めている環境だけが取り残されます。そして自動更新を止めているのは、たいてい「安定稼働を優先している重要なサーバ」です。守りたいものほど古いまま残る、という逆転が起きます。
正直、エージェント類のバージョン管理は後回しにされがちです。OSのパッチは月次で追いかけていても、「AWSが勝手に入れたエージェント」まで台帳に載せている組織は多くないでしょう。今回は、その台帳を1行増やす良い機会だと思います。
まとめ
- CVE-2026-89049は、SSM Agentのポート転送でリンクローカルに到達され、インスタンスのIAMロール一時認証情報を外部から使われるおそれがある脆弱性。
- 修正版3.3.4851.0は2026年7月13日リリース済み。自動更新を止めている環境に古いエージェントが残りやすいので、フリートマネージャーでバージョンを確認する。
- 更新までの緩和策は、
AWS-StartPortForwardingSessionToRemoteHostの利用をIAMで絞ること。更新後も、この機能が本当に必要かを棚卸しする価値がある。
