In this post, I examine what is recorded in AWS CloudTrail when someone attempts to exploit CVE-2026-89049, a CVSS 9.9 vulnerability in the AWS Systems Manager Agent. The goal is to help readers determine whether their environments may have been targeted.
Although the vulnerability has a Critical CVSS rating, its incremental impact depends heavily on how Session Manager permissions are configured. In particular, the risk is different when users already have shell access to the managed instance. I will discuss that distinction after looking at the CloudTrail evidence.
What is CVE-2026-89049?
On September 10, 2026, AWS disclosed CVE-2026-89049, an SSRF vulnerability in the remote-host port forwarding functionality of the AWS Systems Manager Agent, commonly known as the SSM Agent.
The vulnerability affects SSM Agent versions earlier than 3.3.4851.0. An authenticated principal with permission to use AWS-StartPortForwardingSessionToRemoteHost could bypass the destination denylist by using an equivalent representation of a link-local address.
This could allow an authenticated principal with permission to create remote-host port-forwarding sessions to reach the EC2 Instance Metadata Service and potentially obtain the instance profile’s temporary IAM role credentials.
The security impact is particularly significant when that principal is not permitted to open a shell or execute commands on the managed instance, because the vulnerability provides access that the principal would not otherwise have.
RDS is one possible remote destination, but the vulnerable functionality is not limited to RDS.
What happens if it is exploited?
If the temporary IAM role credentials are obtained, an attacker can use them outside the EC2 instance until they expire. The resulting impact is limited by the permissions attached to the instance role.
However, the additional risk introduced by this vulnerability depends on the attacker’s existing permissions.
If the same principal can already open a Session Manager shell or execute commands through SSM Run Command, that principal can normally access IMDS from inside the instance without exploiting this vulnerability. In that situation, CVE-2026-89049 may provide little additional access to the instance role.
The vulnerability is more significant when an organization has deliberately separated these permissions. For example, a developer might be allowed to create a port-forwarding session to an internal database while being denied shell access and Run Command access to the bastion instance itself.
In such an environment, this vulnerability crosses an intentional security boundary: permission to establish a TCP tunnel can potentially become access to the instance profile’s IAM credentials.
If users who can use remote-host port forwarding already have shell access to the same instance, this vulnerability may not provide any meaningful additional access. In that case, it may be reasonable to assign the update a lower priority.
What kind of logs are recorded?
CloudTrail records the StartSession API call and its request parameters, including the target instance, document name, remote host, remote port, and local port.
However, CloudTrail does not record the traffic sent through the port-forwarding tunnel. It also does not indicate whether the SSM Agent successfully connected to the requested destination.
The frequency of remote-host port forwarding varies between organizations. In environments where this Session document is rarely used, the clearest starting point is to search for all uses of:
AWS-StartPortForwardingSessionToRemoteHost
I recommend reviewing every matching event rather than searching only for a literal IMDS address. Equivalent IP address representations can bypass simple string-based searches, and the value recorded in CloudTrail is the original string supplied by the caller.
Searching CloudTrail Logs
Searching directly from the AWS Management Console can be tedious. You have to open Event History, select Event name under Lookup attributes, and search for StartSession.
If there are only a few results, reviewing them manually is manageable. However, if there are many results, you must open each event individually to inspect its request parameters.
CloudTrail Lake could also be used for this investigation. Since I do not use CloudTrail Lake in my personal environment, I used the AWS CLI instead.
aws cloudtrail lookup-events \
--region ap-northeast-1 \
--lookup-attributes \
AttributeKey=EventName,AttributeValue=StartSession \
--output json |
jq '
[
.Events[]
| (.CloudTrailEvent | fromjson)
| select(
.eventSource == "ssm.amazonaws.com"
and
.requestParameters.documentName
== "AWS-StartPortForwardingSessionToRemoteHost"
)
| {
eventTime,
eventID,
principalArn: .userIdentity.arn,
sourceIPAddress,
userAgent,
target: .requestParameters.target,
documentName: .requestParameters.documentName,
reason: .requestParameters.reason,
parameters: .requestParameters.parameters,
sessionId: .responseElements.sessionId,
errorCode,
errorMessage
}
]
| sort_by(.eventTime)
| reverse
'
This command returns CloudTrail events that used AWS-StartPortForwardingSessionToRemoteHost. Review the host value under parameters, together with the principal, source IP address, target instance, and event time.
If the host value contains a link-local address, or an unusual representation of one, it may indicate an attempt to exploit this vulnerability. Because StartSession requires an authenticated AWS principal, such an event should be investigated immediately.
CloudTrail records the successful creation of the Session Manager session, not the result of the SSM Agent’s subsequent connection attempt. In my testing, DNS resolution failure, denylist rejection, and successful access to IMDS all appeared as successful StartSession events with a session ID and no CloudTrail error.
The issue also affects instances configured to require IMDSv2. I confirmed that an IMDSv2 token could be requested through the tunnel and then used to retrieve non-sensitive instance metadata. I did not retrieve the IAM credentials themselves.
In Closing
My personal impression is that the number of organizations for which this vulnerability creates an entirely new path to the instance role credentials may be smaller than the 9.9 score initially suggests.
In many environments, users who are allowed to use an EC2 instance as a bastion host are also allowed to open a shell on that instance. Those users could already access IMDS without exploiting this vulnerability. The vulnerability has a clearer incremental impact in environments that grant only remote-host port forwarding while explicitly denying shell and command execution.
My initial reaction to the 9.9 score was that the issue must have an extremely broad impact. It was only after reproducing it that I realized how much the real-world risk depends on the surrounding permission model.
That was another useful reminder that hands-on testing often reveals details that a severity score alone cannot show.
Top comments (0)