CVE-2026-89049

What it actually does

The AWS Systems Manager Agent (SSM Agent) port-forwarding-to-remote-hosts path does not canonicalize equivalent forms of a destination address before applying its remote-destination denylist. On agent versions before 3.3.4851.0, an authenticated caller who can start a remote port-forward session can therefore cause the agent to connect to a link-local endpoint that the denylist was intended to block, including the instance metadata service. That can expose the managed instance’s temporary instance-profile IAM credentials and allow those credentials to be used off-instance with the role’s permissions. Impact is to confidentiality of credentials and to subsequent AWS API authorization; the issue is not a remote unauthenticated RCE of the agent itself.

Why it matters to the business

If abused, limited SSM session rights can be turned into use of a managed instance’s IAM role from outside that instance, putting any AWS data, compute, secrets, or downstream services that role can reach at risk. SSM Agent is the default management agent on many EC2 and hybrid nodes, so unpatched fleets amplify blast radius even though no customer-specific inventory is implied here. The issue is not in CISA KEV, is not associated with ransomware use, has no reported public exploit maturity, and EPSS is low and flat (~0.0066 over 30 days). The CVSS 9.9 rating, credential-theft outcome, and 32 days since publication still justify treating fleet-wide agent upgrades as urgent rather than routine.

How an attack unfolds

An attacker who already holds identity permissions sufficient to start an SSM Session Manager remote port-forward to a managed instance running a vulnerable agent supplies a destination host that is a non-canonical equivalent of a denylisted link-local address. The agent fails to treat that value as denied and opens the forward. The attacker then uses the tunnel to reach link-local services on the instance—most critically the instance metadata service—reads temporary IAM role credentials, and calls AWS APIs as that role from a location that is not the instance. No named threat actors or in-the-wild campaigns are indicated in the provided data; exploit maturity is none.

How to fix it

Upgrade Amazon SSM Agent to 3.3.4851.0 or later on every platform (Linux, Windows, and hybrid/on-premises nodes). Prefer fleet-wide deployment through AWS Systems Manager Run Command, State Manager, or the same golden-image/CI pipeline used to ship the agent; confirm the running version after install and reboot or restart the agent service if required. Until the upgrade is complete, tightly restrict who can call ssm:StartSession (and related session documents that forward to a caller-specified remote host), remove unused session privileges, and treat instance-profile roles as high-value: least-privilege policies, short credential lifetime, and no standing admin on those roles. If compromise is suspected, rotate or replace instance-profile roles and invalidate active sessions rather than only patching. Enforcing IMDSv2 is good hygiene but is not a complete substitute for the agent upgrade, because the vulnerable component runs on the instance and can still reach link-local services.

How to confirm the fix worked

Inventory agent versions via Systems Manager inventory, the SSM console, or the on-host agent version interface and verify every managed node reports 3.3.4851.0 or later. Confirm agent packages in AMIs, launch templates, and hybrid activation images have been rebuilt. Review IAM policies and session documents for StartSession/port-forward rights that are broader than needed. Do not validate by attempting denylist bypasses or crafting alternate address forms; treat any such test as unnecessary risk. After patching, spot-check that new remote port-forward sessions to explicitly denied link-local destinations are rejected by the updated agent and that CloudTrail still records session starts for audit.

Typical attack path

1. Obtain an identity that is allowed to start SSM Session Manager port forwarding to a managed instance whose agent is older than 3.3.4851.0.
2. Initiate a remote port-forward whose destination host is a non-canonical equivalent of a denylisted link-local address so the agent’s denylist does not match.
3. Use the resulting tunnel to reach link-local endpoints on the instance, especially the instance metadata service.
4. Collect the instance profile’s temporary IAM credentials from metadata.
5. Invoke AWS APIs with those credentials from outside the instance, within the role’s existing permissions.

How to detect it

There is no public exploit maturity and no named actor set, so look for misuse of legitimate SSM and AWS identity telemetry rather than a unique malware family. In AWS CloudTrail (management events, all regions), search for ssm.amazonaws.com StartSession (and related ResumeSession/TerminateSession) where the session document forwards to a caller-specified remote host, especially around and after 2026-09-10. On instances, review Amazon SSM Agent logs for remote port-forward activity whose destination is link-local or otherwise unexpected. The highest-confidence post-exploitation signal is CloudTrail or IAM Access Analyzer evidence that an instance-profile role’s access key was used from a source IP, geolocation, user agent, or service that does not match that instance—GetCallerIdentity, sts, and follow-on data-plane calls shortly after a port-forward session. Host telemetry may show the agent process connecting to 169.254.169.254 or other link-local addresses during a session. IMDS hop-limit and VPC flow logs often will not show this traffic because it is on-instance and link-local. Correlate any hit with agent version at the time (vulnerable if older than 3.3.4851.0).

• eventSource=ssm.amazonaws.com AND eventName=StartSession
• AWS-StartPortForwardingSessionToRemoteHost
• /var/log/amazon/ssm/amazon-ssm-agent.log
• %PROGRAMDATA%\Amazon\SSM\Logs\amazon-ssm-agent.log
• amazon-ssm-agent
• 169.254.169.254
• /latest/meta-data/iam/security-credentials/
• 169.254.169.254/latest/api/token
• userIdentity.type=AssumedRole used from sourceIPAddress not matching the originating instance

What your security team should do

• Patch SSM Agent to 3.3.4851.0 or later across all managed instances and hybrid nodes as the primary control; do not wait on KEV listing given CVSS 9.9 and credential impact.
• Immediately inventory nodes still below 3.3.4851.0 and prioritize internet-reachable, production, and high-privilege instance-profile workloads.
• Reduce ssm:StartSession and remote port-forward document use to the minimum identities and resources required; alert on new grants.
• Hunt CloudTrail and identity findings for instance-role credentials used from source IPs or user agents that are not the instance itself, especially around 2026-09-10 and after.
• Rebuild golden images and automation so new instances never launch with a vulnerable agent.
• If exposure is confirmed, rotate instance-profile credentials/roles, end active SSM sessions, and review AWS API activity performed by those roles.