Guides

AWS SSM Agent lets attackers quietly become root

Q: What is the SSM Agent?

What is the SSM Agent? The AWS Systems Manager Agent is the software on a managed instance that receives jobs from Systems Manager. These include Run Command, Patch Manager and Session Manager. Each job arrives as a document; the agent starts the matching plugin on the machine.

CVE-2026-81849: The agent writes as root outside the download folder. The fix has been available since May.

By Alec Chizhik August 29, 2026 4 min read

AWS SSM Agent lets attackers quietly become root

On nearly every managed instance, the SSM Agent waits for jobs from the cloud. AWS published Bulletin 2026-091 and CVE-2026-81849 on 28 August; the patch has been available since 21 May. Fleet Manager shows which instances already carry the corrected version.

Key takeaways

If the agent version in Fleet Manager is below 3.3.4515.0, the fix is missing. Check the version column first.
The download plugin can place files as root outside the download folder.
AWS names no workaround. Anyone who does not update the agent leaves the write path open.

Related:AWS Identity Center: multi-region is now part of the setup / AWS Cognito: Skill resets the client

The patch has been in the agent since May

AWS shipped the patch on 21 May in version 3.3.4515.0. Bulletin 2026-091 and CVE-2026-81849 followed on 28 August. Anyone who did not update the agent during that period is still running the old version. The researcher wareeqshile reported the flaw through coordinated disclosure.

Agent versions from 2.0.767.0 to 3.3.4364.0 are affected. The affected version range extends far back, so older installations are also affected. From 3.3.4515.0 onward, the write path is closed. Amazon assigns the flaw a score of 8.7 under CVSS 4.0. AWS names no workaround. Anyone who waited for the 28 August bulletin alone missed the May fix for three months.

On 2 June, version 3.3.4624.0 tightened the internal path check once again. Anyone on 3.3.4515.0 or newer already has the fix for the flaw.

The download plugin writes as root

AWS-DownloadContent triggers the file retrieval from S3. The plugin fetches the object and writes the file as root. If the object name contains path components, the file lands outside the intended download folder. If sensitive system files are overwritten in the process, this can result in code execution as root. The agent runs with these rights on the instance; that is exactly why this one write path is enough.

The impact is limited to the machine where the agent runs. The bulletin names EC2 instances, edge devices, on-premises servers and virtual machines. The bulletin does not list accounts, services and customer data in AWS itself as affected.

The prerequisite is the permission to trigger AWS-DownloadContent via Run Command. Restricting access to this exact document still leaves the write path open; unauthenticated access from the network is not enough.

The version is shown in Fleet Manager

The quickest way to check the agent version is through Fleet Manager. It has a column for the SSM Agent version. If the value is below 3.3.4515.0, the fix is missing. That applies to EC2 just as it does to machines outside AWS that Systems Manager connects to: on-premises servers, virtual machines and edge devices. Anyone who checks the column sees the version per node. The Fleet Manager column documents the current agent version for every EC2 and hybrid node with the agent installed, before anyone updates the agent.

AWS can update the agent on its own across an entire account. The Auto-Update option in Fleet Manager checks every two weeks and rolls out new versions via the AWS-UpdateSSMAgent document. Only this column shows whether a fleet already carries the fix. An estimate based on the image date is no substitute for looking at the column.

Anyone who has not enabled Auto-Update stays on the version the instance launched with until someone updates the agent. The biweekly run only helps if the option is actually active.

AMIs and golden images keep the old version

Amazon Linux and Windows AMIs often ship with the agent already included. The bundled version is often not the newest. Anyone launching an image from the catalog therefore does not automatically get the patched agent.

Instances launched from golden images created in the spring run the same old agent whenever a launch template continues to use those images. The image itself stays old until someone replaces it. A rebuild of the image updates the agent on new instances; instances already running stay on their version until the agent is updated there. Launch templates that hold a fixed image ID do not change this as long as the ID stays the same.

Frequently asked questions

What is the SSM Agent?

What is the SSM Agent? The AWS Systems Manager Agent is the software on a managed instance that receives jobs from Systems Manager. These include Run Command, Patch Manager and Session Manager. Each job arrives as a document; the agent starts the matching plugin on the machine.

Is removing AWS-DownloadContent from the IAM list enough?

With that in place, the plugin can no longer be invoked by authorized callers. It does not replace the update. The flaw remains until the agent has been updated.

Do I have to rebuild golden images?

Yes, if the image itself ships with the agent version.

What does version 3.3.4624.0 change compared with 3.3.4515.0?

On 2 June, 3.3.4624.0 tightened the internal path check. The fix for the flaw itself starts at 3.3.4515.0.

Is AWS itself affected?

AWS limits the impact to the machine where the agent runs. The bulletin does not list accounts, services and customer data in AWS itself as affected.