Server-side request forgery in AWS Amazon SSM Agent port forwarding can expose instance IAM credentials

A server-side request forgery issue due to improper validation of equivalent address representations in the port forwarding to remote hosts functionality in Amazon AWS Systems Manager Agent (SSM Agent) before 3.3.4851.0 on all platforms might allow an authenticated remote user to bypass the remote destination denylist and reach link-local endpoints, potentially obtaining the temporary IAM role credentials of a managed instance and acting with that role's permissions from outside the instance, via a crafted destination host value that uses an alternate representation of a denied link-local address. To remediate this issue, users should upgrade to version 3.3.4851.0 or later.

• AWS Amazon SSM Agent: the CNA record marks versions from 0 through before 3.3.4851.0 as affected on all platforms. • AWS describes the practical scope as all versions supporting remote-host port forwarding. • 3.3.4851.0 is the release confirmed to contain the fix. Parallel release branches and derivative builds remain unverified unless checked separately.

AWS Amazon SSM Agent processes requests for Systems Manager capabilities, including Session Manager port forwarding to remote hosts. The flaw is an unsafe-equivalence validation failure: the agent did not reliably recognize alternate representations of the same denied address, allowing an attacker-controlled destination host value to bypass the remote destination denylist for link-local addresses. Exploitation requires an authenticated user with permission to start remote-host port-forwarding sessions, but no additional user interaction is required. Reaching a link-local endpoint, primarily the Instance Metadata Service, may expose the managed instance's temporary IAM role credentials, which can then be used from outside the instance. The complete implementation details of address parsing and all accepted alternate representations are not public, although the associated release notes confirm that canonicalizing IP addresses before the denylist check is part of the fix.

The issue is reachable through the network-facing Session Manager remote-host port-forwarding workflow. An attacker must be authenticated and authorized to use that workflow, including the relevant session and SSM document permissions. No victim interaction is required, and the condition is described as low complexity. The supplied record does not mark the issue as known exploited and does not report a public exploit; that is a reporting status, not proof that exploitation is absent.

The flaw lets an authenticated user redirect the agent to a link-local endpoint instead of only an approved destination. The primary technical outcome is possible access to the managed instance's temporary IAM role credentials, followed by use of those credentials from outside the instance. This creates a scope change from access to the managed-node session workflow to the AWS APIs authorized for the IAM role. Integrity or availability consequences depend on the role's write and administrative permissions and are not uniform across deployments.

• Temporary credentials for a managed instance's IAM role may become accessible from outside the instance. • An attacker could call AWS APIs within the role's permissions, creating a risk of unauthorized access to data or cloud resources. • The practical blast radius depends on the role policy, trust boundaries, and accessible resources; the record does not establish that every deployment permits data modification or service disruption. • Environments that allow untrusted principals to start remote-host port-forwarding sessions have greater exposure and should prioritize permission review.

1. Upgrade affected AWS Amazon SSM Agent deployments to 3.3.4851.0. Verify parallel branches, forks, and derivative builds separately rather than assuming they inherit the fix.
2. Until the agent is upgraded, restrict use of the AWS-StartPortForwardingSessionToRemoteHost document by narrowing ssm:StartSession IAM permissions and SSM document permissions so untrusted principals cannot start remote-host port-forwarding sessions.
3. For forked or derivative code, incorporate the equivalent fixes, including IP canonicalization before the remote destination denylist check and the denylist updates for loopback and ECS or EKS credential endpoints.
4. After remediation, confirm that the asset inventory reflects the fixed release and reassess every principal that retains remote-host port-forwarding access.

1. Inventory SSM Agent versions across all managed nodes, including EC2 instances, on-premises servers, and other supported systems, then identify agents in the affected branch.
2. Identify nodes that support or use remote-host port forwarding, especially sessions using the AWS-StartPortForwardingSessionToRemoteHost SSM document.
3. Review IAM policies and SSM document permissions for principals that have ssm:StartSession and remote-host port-forwarding access without a documented business need.
4. Review recent remote-host port-forwarding activity and requests directed at link-local endpoints as a precautionary investigation step. Logs that do not preserve or distinguish alternate destination representations cannot rule out exploitation.
5. For forks or derivative builds, verify that the fix canonicalizes addresses before the denylist check and includes the related denylist changes for loopback and ECS or EKS credential endpoints.