SSM Agent Vulnerability CVE-2026-89049: Is Your Fleet Still Exposed?

On 10 September, AWS published a bulletin for an SSM Agent vulnerability, CVE-2026-89049, rated 9.9 on CVSS. Anyone with permission to start a Session Manager port-forwarding session to a remote host could reach the instance metadata service through the agent and walk away with the instance role's temporary credentials. Those credentials work from a laptop anywhere, with whatever permissions the role has.

The part that should bother a CTO is not the bug. It is the date on the fix. SSM Agent 3.3.4851.0, the patched version, was released on 13 July. If your instances update the agent automatically, you were protected before anyone told you there was a problem. If they run whatever was baked into the AMI, a two-month-old fix has been sitting unapplied on every box.

Which of those fleets you have takes ten minutes to answer. Most teams we talk to have never asked.

What does the SSM Agent vulnerability actually let someone do?

Session Manager has a document called AWS-StartPortForwardingSessionToRemoteHost. It is genuinely useful: an engineer tunnels from their machine, through an instance, to something the instance can reach, such as an RDS endpoint in a private subnet, with no bastion and no open port. The agent keeps a denylist so the tunnel cannot be pointed at link-local addresses, which is where the instance metadata service lives.

The advisory says the denylist did not canonicalise addresses before checking them, so an equivalent way of writing the same address slipped past. That is all the detail this post needs. A person who was allowed to forward a port could ask the metadata service for the instance profile's credentials and use them as ordinary AWS API credentials outside the instance.

Two preconditions matter. The attacker has to be authenticated, with ssm:StartSession on that document. And what they get is bounded by the instance role. So this is an escalation from "can open a tunnel" to "is the instance", and how bad that is depends entirely on what the instance is allowed to do.

Why is a fix from July still missing in September?

Because SSM Agent is one of those components nobody owns. It comes preinstalled on Amazon Linux, Ubuntu and Windows AMIs, it just works, and the person who built the AMI pipeline has moved on. The version on an instance is whatever was on the AMI the day it was built, unless something updates it afterwards.

AWS gives you three ways to make that happen: the Auto update SSM Agent setting in Fleet Manager, which checks every two weeks and runs AWS-UpdateSSMAgent; a State Manager association you write yourself, optionally inside a maintenance window; or the Quick Setup host management option, also fortnightly. All three are opt-in. A fresh account has none of them.

The pattern we see in audits is consistent. Auto-update was turned on in the account someone set up by hand in 2023 and never added to the Terraform that stamps out the accounts that came after, so production has it and the newer environments do not. Or the golden AMI pipeline bakes the agent, the team is proud of the pipeline, and it has not run since March because nothing forced it to.

Neither is negligence. It is just that "we patch" turned out to mean "we patch the things that page us".

Which instances are still running the old SSM Agent?

This is the ten-minute check. Run it in every account and region you care about:

aws ssm describe-instance-information \
  --query "InstanceInformationList[?PingStatus=='Online'].[InstanceId,PlatformName,AgentVersion,IsLatestVersion]" \
  --output table

Anything with an AgentVersion below 3.3.4851.0 is affected. Do not lean on the IsLatestVersion column: the API reference says it is not reliable for Windows nodes, and "latest" is a moving target that may be newer than the fix. Compare the number.

Then drop the PingStatus filter and look at what comes back as ConnectionLost. An agent that stopped talking to Systems Manager cannot be patched by it, and it is probably also on the instance nobody is watching.

If the list has old versions on it, the fastest fix is Run Command with AWS-UpdateSSMAgent against those instance ids, then Fleet Manager auto-update so you do not have this conversation again in six months. Bottlerocket is the exception: its agent updates through the control container, not that document.

Who in your account can start a port-forwarding session?

The patch is the fix. But the advisory's own workaround is to scope ssm:StartSession so untrusted principals cannot start remote-host port forwarding, and that is worth doing permanently.

Session Manager treats the document as a resource of ssm:StartSession, which makes this easy. AWS's sample end-user policies already allow the action only on a specific instance ARN plus a specific document, usually SSM-SessionManagerRunShell. If your policies look like that, port forwarding is not allowed and you are fine. If they say "Resource": "*", everyone with shell access also has tunnel access, and that is the population the CVE applies to.

Two things to do on Monday. First, find out who has actually used it. CloudTrail's event history covers ninety days, which is the whole window since the fix shipped:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=StartSession \
  --start-time 2026-07-13 \
  --query "Events[].CloudTrailEvent" --output text \
  | grep -c AWS-StartPortForwardingSessionToRemoteHost

Second, if the answer is zero or "only the two platform engineers", say so in IAM. Add an explicit deny to the permission set or role everyone else uses:

{
  "Effect": "Deny",
  "Action": "ssm:StartSession",
  "Resource": "arn:aws:ssm:*:*:document/AWS-StartPortForwardingSessionToRemoteHost"
}

Then give the people who need it a separate, narrower allow, scoped by tag to the instances they tunnel through, as the AWS admin sample does with ssm:resourceTag. In every account we have looked at, fewer people need to forward ports through production than can.

How much can the instance role do once it leaves the box?

The credentials an attacker gets are exactly the instance profile's. That is either reassuring or alarming depending on how the role was written, and it is usually written badly for the same reason the agent is not updated: nobody owns it.

The bastion role with AdministratorAccess because someone needed to debug something in 2024. The application role with s3:* on * because scoping buckets was fiddly. The CI runner whose role can assume the deploy role in every account. On any of those, this CVE is "someone with a tunnel is now an admin from their laptop, and CloudTrail attributes it to the instance".

We made the same argument about GitHub Actions in the July checkout post: the fix that removes the prize is worth more than the fix that closes one door. Here the prize is the role. Run IAM Access Analyzer's unused-access findings against your instance profiles and take away what has not been used in ninety days. For roles that only ever act from inside the VPC, deny use from anywhere else (aws:SourceVpc through VPC endpoints, aws:SourceIp on your NAT addresses otherwise), tested on one role first. Credentials that stop working the moment they leave the network are a much smaller thing to have stolen.

What do the RBI and CERT-In expect you to have done?

If you hold an NBFC licence, the RBI's 2026 cybersecurity direction asks, in paragraph 125, for known vulnerabilities to be fixed in a time-bound manner and for the fix to be sustained; paragraph 126 says the same applies to systems in the cloud. We walked through the direction in the NBFC post. A critical CVE with a vendor patch available since July is the textbook case, and "the AMI was built before the patch" is not an answer an auditor has to accept.

Then the incident side. If the CloudTrail search turns up port-forwarding sessions from principals who should not have them, on instances unpatched at the time, you have to decide whether that is an incident, and the CERT-In clock does not wait while you do. Six hours from detection is the number, and if a DevOps vendor runs the account, their delay in telling you eats into your six. Revoke the role's active sessions in IAM first, so any credentials already taken stop working, then decide.

Should you just turn Session Manager off?

No, and it is worth being fair about why. Session Manager is still a better answer than SSH keys and a bastion: no inbound port, every session in CloudTrail with a real identity behind it, output recordable to S3, nothing to rotate when someone leaves. What most teams would fall back to is worse on every axis a regulator cares about.

The honest concession runs the other way. Automatic agent updates mean a process running as root on every instance you own pulls new code from AWS every fortnight with no human in the loop. Some teams pin the agent and take updates only through their AMI pipeline, so a change is reviewed before it lands on production. That is defensible, but only if the pipeline actually runs and someone reads the release notes when it does. Pinning without either is not control; it is the outcome above with a better story attached.

If you never use remote-host port forwarding, deny the document account-wide and patch on your normal cadence. If you do use it, patch this week and narrow who can.

The short version

Run describe-instance-information in every account today and list anything below 3.3.4851.0. Update those with AWS-UpdateSSMAgent, then turn on auto-update or fix the AMI pipeline so July does not happen again. Search CloudTrail for port-forwarding sessions since 13 July and decide whether what you find is an incident. Deny AWS-StartPortForwardingSessionToRemoteHost for everyone who does not need it. Then spend the time you saved on the instance roles, because the next agent bug will hand someone the same credentials.

Two months is how long this fix sat unapplied on fleets where nobody watched the agent. The version number is the only thing that tells you whether yours was one of them.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.