AWS SSM-Agent lässt Angreifer heimlich Root werden
CVE-2026-81849: der Agent schreibt als Root neben dem Download-Ordner. Der Fix liegt seit Mai.
Auf fast jeder verwalteten Instanz wartet der SSM-Agent auf Aufträge aus der Cloud. AWS veröffentlichte Bulletin 2026-091 und CVE-2026-81849 am 28. August; der Patch liegt seit dem 21. Mai bereit. Fleet Manager zeigt, welche Instanzen den korrigierten Stand bereits tragen.
Das Wichtigste in Kürze
- Liegt die Agent-Version in Fleet Manager unter 3.3.4515.0, fehlt der Fix. Zuerst die Versions-Spalte prüfen.
- Das Download-Plugin kann Dateien als Root außerhalb des Download-Ordners ablegen.
- AWS nennt keinen Workaround. Wer den Agenten nicht nachzieht, lässt den Schreibweg offen.
Verwandt:AWS Identity Center: Multi-Region sitzt jetzt im Setup / AWS Cognito: Skill setzt den Client zurück
Der Patch liegt seit Mai im Agent
AWS hat den Patch am 21. Mai in Version 3.3.4515.0 ausgeliefert. Bulletin 2026-091 und CVE-2026-81849 folgten am 28. August. Wer in diesem Fenster den Agenten nicht nachgezogen hat, fährt weiter mit dem alten Stand. Der Forscher wareeqshile hat die Lücke über das koordinierte Verfahren gemeldet.
Betroffen sind Agent-Stände von 2.0.767.0 bis 3.3.4364.0. Die untere Grenze reicht weit zurück; es trifft also nicht nur frische Installationen. Ab 3.3.4515.0 ist der Schreibweg geschlossen. Amazon weist der Schwäche 8,7 Punkte nach CVSS 4.0 zu. AWS nennt keinen Workaround. Wer nur das Bulletin vom 28. August abwartet, hat den Mai-Stand drei Monate lang übersehen.
Am 2. Juni hat Version 3.3.4624.0 die interne Pfadprüfung noch einmal nachgezogen. Wer schon auf 3.3.4515.0 oder neuer steht, hat den Fix der Lücke.
Das Download-Plugin schreibt als Root
AWS-DownloadContent stößt den Dateiabruf aus S3 an. Das Plugin holt das Objekt und schreibt die Datei als Root. Trägt der Objektname Pfadanteile, landet die Datei außerhalb des vorgesehenen Download-Ordners. Werden dabei empfindliche Systemdateien überschrieben, kann das in Codeausführung als Root münden. Der Agent läuft mit diesen Rechten auf der Instanz; genau deshalb reicht der eine Schreibweg.
Der Schaden sitzt auf der Maschine, auf der der Agent läuft. Das Bulletin nennt EC2-Instanzen, Edge-Geräte, Server vor Ort und virtuelle Maschinen. Konten, Dienste und Kundendaten in AWS selbst nennt das Bulletin nicht als betroffen.
Voraussetzung ist das Recht, AWS-DownloadContent per Run Command auszulösen. Eine Begrenzung auf genau dieses Dokument hält den Schreibweg offen; ein Zugriff ohne Anmeldung aus dem Netz reicht nicht.
Die Version steht in Fleet Manager
Der kürzeste Weg zum Stand ist Fleet Manager. Dort gibt es eine Spalte für die SSM-Agent-Version. Liegt der Wert unter 3.3.4515.0, fehlt der Fix. Das gilt für EC2 genauso wie für Rechner außerhalb von AWS, die Systems Manager anbindet: Server vor Ort, virtuelle Maschinen und Edge-Geräte. Wer die Spalte prüft, sieht den Stand je Knoten. Die Spalte in Fleet Manager dokumentiert den laufenden Agent-Stand je EC2-Knoten und je Hybrid-Knoten, also für jede Maschine mit installiertem Agenten, bevor jemand den Agenten nachzieht.
AWS kann den Agenten kontenweit selbst nachziehen. Die Option Auto-Update im Fleet Manager prüft alle zwei Wochen und spielt neue Stände über das Dokument AWS-UpdateSSMAgent aus. Ob eine Flotte den Fix schon trägt, zeigt erst diese Spalte. Eine Schätzung nach Image-Datum ersetzt den Blick in die Spalte nicht.
Wer Auto-Update nicht gesetzt hat, bleibt auf dem Stand, mit dem die Instanz gestartet ist, bis jemand den Agenten nachzieht. Der zweiwöchentliche Lauf hilft nur, wenn die Option wirklich aktiv ist.
AMIs und Golden Images halten den alten Stand
Amazon-Linux- und Windows-AMIs bringen den Agenten oft schon mit. Der mitgelieferte Stand ist oft nicht der neueste. Wer ein Image aus dem Katalog startet, startet deshalb nicht automatisch den gepatchten Agenten.
Golden Images aus dem Frühjahr starten denselben alten Agenten, sobald eine Launch-Vorlage sie weiter verwendet. Das Image selbst bleibt alt, bis jemand es ersetzt. Ein Rebuild des Images zieht den Agenten auf neuen Instanzen nach; schon laufende Instanzen bleiben auf ihrem Stand, bis der Agent dort nachgezogen wird. Launch-Vorlagen, die eine feste Image-ID halten, ändern daran nichts, solange die ID gleich bleibt.
Häufige Fragen
Was ist der SSM-Agent?
Was ist der SSM-Agent? Der AWS Systems Manager Agent ist die Software auf einer verwalteten Instanz, die Aufträge aus Systems Manager entgegennimmt. Dazu gehören Run Command, Patch Manager und Session Manager. Jeder Auftrag kommt als Dokument an; der Agent startet dafür das passende Plugin auf dem Rechner.
Reicht es, AWS-DownloadContent aus der IAM-Liste zu streichen?
Damit darf das Plugin nicht mehr berechtigt aufgerufen werden. Es ersetzt das Update nicht. Die Lücke bleibt, bis der Agent nachgezogen ist.
Muss ich Golden Images neu bauen?
Ja, wenn das Image selbst den Agentenstand mitbringt.
Was ändert Version 3.3.4624.0 gegenüber 3.3.4515.0?
Am 2. Juni hat 3.3.4624.0 die interne Pfadprüfung nachgezogen. Der Fix der Lücke selbst beginnt bei 3.3.4515.0.
Sitzt der Schaden in AWS selbst?
AWS grenzt den Impact auf die Maschine ein, auf der der Agent läuft. Konten, Dienste und Kundendaten in AWS selbst nennt das Bulletin nicht als betroffen.
Lesetipps der Redaktion
cloudmagazinAWS AgentCore bringt Memory in die GovCloudcloudmagazinTimestream-Backup: Restore ohne TicketcloudmagazinLambda Managed Instances: Logs, die man brauchtMehr aus dem MBF Media Netzwerk
MyBusinessFutureMcKinsey: KI macht schnell, der EBIT bleibt flachDigital ChiefsOpenAI senkt Tokenpreise, Agenten fressen die ErsparnisSecurityTodayRed Team gegen KRITIS: Selbst das gute SOC verliertQuelle: AWS Security Bulletin 2026-091-AWS, 28. August 2026.
Bildquelle: KI-generiert (August 2026)
Auch verfügbar in
