An IAM user with ssm:SendCommand, locked down to a single Systems Manager document, was supposed to be able to do exactly one thing: pull a file from S3 onto an instance. Until last week, that was also enough to write files anywhere on the machine as root.
Amazon Web Services disclosed the flaw, tracked as CVE-2026-81849, on 28 August in security bulletin 2026-091-AWS. It sits in the aws:downloadContent plugin of amazon-ssm-agent, the AWS Systems Manager Agent that runs on EC2 instances, edge devices, on-premises servers and virtual machines so Systems Manager can update, manage and configure them.
According to AWS, the agent does not properly limit where a downloaded file can land. An authenticated remote user whose ssm:SendCommand permission is restricted to the AWS-DownloadContent document can supply specially crafted S3 object keys and write arbitrary files outside the intended download directory, with root privileges. AWS says that overwriting specific sensitive files may lead to arbitrary code execution as root. The CVE record carries a CVSS 4.0 base score of 8.7, rated high. AWS credits wareeqshile for reporting the issue through its coordinated disclosure process.
The blast radius is your SSM fleet, not one product
Impacted builds run from amazon-ssm-agent 2.0.767.0 through 3.3.4364.0. Because the agent is a management component rather than an application, the exposure tracks how widely an organization uses Systems Manager rather than which version of any one product it happens to run.
Neither the AWS bulletin nor the CVE record asserts that the flaw has been exploited. What makes it worth attention is the shape of the privilege jump rather than any observed attack: ssm:SendCommand scoped to a single document is precisely the sort of narrow grant handed out on the assumption that it cannot lead anywhere. The containment was living in the agent's file handling, not in the IAM policy.
Upgrade to 3.3.4515.0, because there is no workaround
AWS fixed the issue in amazon-ssm-agent 3.3.4515.0 and states plainly that no workarounds are available, which makes upgrading the only option. It also recommends that anyone running forked or derivative code apply the same fix.
Peru's Centro Nacional de Seguridad Digital reissued the advisory on 29 August as integrated digital security alert 161-2026, adding operational guidance for defenders in Peru and anywhere else. The CNSD recommends inventorying every EC2 instance, on-premises server, virtual machine and device where amazon-ssm-agent is installed; reviewing the IAM policies that grant ssm:SendCommand and cutting them back to least privilege; identifying which accounts can run the AWS-DownloadContent document; and watching Systems Manager, CloudTrail and S3 logs for unusual SendCommand activity or aws:downloadContent downloads, alongside unauthorized changes to sensitive files.
That last item is the one worth doing after the agent is patched, not before. A path traversal that writes as root leaves its evidence in the filesystem, and a fleet that has been running an affected agent build has had a long window in which to accumulate some. Our recent look at which cloud findings are real attack paths makes the same argument from the other end: the finding that matters is the one where a small permission reaches somewhere it should not.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.