Ograniczone ssm:SendCommand, a plik zapisany jako root — CVE-2026-81849 i ukryta granica zaufania w AWS SSM Agent

W chmurze bardzo łatwo spojrzeć na IAM policy i uznać: „to konto ma ograniczone uprawnienia, więc skutki kompromitacji też będą ograniczone”. CVE-2026-81849 w Amazon SSM Agent pokazuje, dlaczego takie rozumowanie bywa błędne — i dlaczego least privilege trzeba oceniać nie na poziomie pojedynczego API, lecz całego łańcucha wykonania.

Podatność dotyczy pluginu aws:downloadContent w amazon-ssm-agent przed wersją 3.3.4515.0. Użytkownik, którego uprawnienie ssm:SendCommand jest ograniczone do dokumentu AWS-DownloadContent, może przez odpowiednio przygotowane klucze obiektów S3 spowodować zapis plików poza zakładanym katalogiem pobierania. A ponieważ SSM Agent działa z wysokimi uprawnieniami, zapis odbywa się z uprawnieniami root.

limited cloud permission → arbitrary file write as root → overwrite sensitive file → root code execution

Co mówi CVE?

CVE-2026-81849 zostało opublikowane 28 sierpnia 2026 przez Amazon.

Affected: amazon-ssm-agent < 3.3.4515.0.

Fix: 3.3.4515.0.

CVSS 3.1: 8.8 High — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

CVSS 4.0: 8.7 High.

CWE-23: Relative Path Traversal.

Na pierwszy rzut oka PR:L i severity High nie wyglądają tak dramatycznie jak unauthenticated RCE. Ale kontekst zmienia ocenę.

Co właściwie może zrobić atakujący?

Atakujący musi posiadać uprawnienie umożliwiające użycie SSM SendCommand dla dokumentu AWS-DownloadContent. To może wyglądać na mocno ograniczone prawo — użytkownik nie musi mieć pełnego ssm:*, dostępu SSH, konta systemowego na EC2, sudo ani bezpośredniego roota. A mimo to podatny agent wykonuje operację lokalnie z wysokimi uprawnieniami. Jeśli klucze obiektu S3 zostaną przygotowane tak, aby wykorzystać path traversal, plik trafia poza katalog docelowy. I wtedy zakres możliwości zależy już tylko od tego, co można nadpisać na hoście.

IAM permission nie pokazuje effective privilege

To kluczowy wniosek. IAM mówi „user can call AWS-DownloadContent”, ale nie mówi „what can the SSM Agent do on the operating system?”. Agent jest zaufanym mostem między control plane AWS a hostem:

IAM principal ↓ SSM API ↓ SSM Agent ↓ local filesystem ↓ root privileges

Jeżeli którykolwiek etap źle waliduje dane wejściowe, pozornie ograniczone uprawnienie cloudowe może przekroczyć granicę systemu operacyjnego.

Least privilege to property całego chainu

Organizacja może mieć policy pozwalającą wyłącznie na ssm:SendCommand do zasobu AWS-DownloadContent. Security review powie: „użytkownik może tylko pobierać content”. Ale jeśli implementacja dokumentu pozwala wyjść poza katalog, realne uprawnienie staje się write arbitrary local files as root. Prawdziwe least privilege musi więc uwzględniać iloczyn:

IAM permission × server-side implementation × local execution privilege

Nie tylko pierwszy element.

Management agents to high-value software

SSM Agent jest narzędziem administracyjnym. Takie komponenty powinny mieć podwyższony asset criticality, ponieważ działają z wysokimi uprawnieniami, posiadają kanał zdalnego zarządzania, integrują chmurę z systemem operacyjnym i często są obecne na bardzo dużej liczbie hostów. To sprawia, że CVE w management-plane agent może mieć znacznie większe znaczenie niż CVE o podobnym CVSS w zwykłej aplikacji użytkownika.

CVSS 8.8 nie znaczy „mniej pilne niż każde 9.8”

Jeżeli organizacja sortuje backlog wyłącznie ORDER BY cvss DESC, CVE-2026-81849 może znaleźć się za tysiącami Critical. Ale zapytajmy: czy SSM Agent jest wszędzie? Czy działa jako root? Ilu principals ma SendCommand? Czy hosty są produkcyjne? Czy przejęcie jednego hosta daje lateral movement? W takim środowisku 8.8 może być bardzo pilnym P1.

Co powinien sprawdzić Vulnerability Engineer?

Inventory agentów — które instancje EC2/hybrid uruchamiają amazon-ssm-agent.
Version — czy < 3.3.4515.0.
IAM exposure — kto ma ssm:SendCommand, dostęp do AWS-DownloadContent i możliwość uruchamiania dokumentów na produkcji.
Target scope — czy policy pozwala atakować pojedynczy host, grupę po tagach, czy cały account.
Host criticality — czy agent działa na bastionie, CI/CD, serwerze bazodanowym, production application host albo security tooling.

IAM review jako część VM enrichment

Ten sam CVE na dwóch hostach to nie to samo ryzyko. Finding może wyglądać tak:

cve: CVE-2026-81849 asset: i-012345 agent_version: 3.3.4300.0 cloud_context: ssm_managed: true sendcommand_principals: 18 aws_downloadcontent_allowed: true host: criticality: high environment: production priority: P1

A dla innego hosta: sendcommand_principals: 0, network_isolated: true, criticality: low → priority: P3. To ten sam CVE, ale inne ryzyko.

Czy można mitygować bez patcha?

Najlepsza remediation to upgrade amazon-ssm-agent to 3.3.4515.0+. Jeżeli upgrade nie jest natychmiast możliwy, można czasowo ograniczyć ssm:SendCommand, użycie AWS-DownloadContent, scope targetowania oraz role i użytkowników posiadających to prawo. To przykład compensating control na poziomie IAM. Dojrzały VM powinien umieć zapisać: component vulnerable but exploit path temporarily restricted by IAM — wraz z terminem ponownej walidacji.

A jeśli uprawnienie posiada CI/CD?

Wtedy sytuacja może być poważniejsza. Jeżeli pipeline ma prawo uruchamiania AWS-DownloadContent, kompromitacja CI/CD prowadzi do: CI token → SSM command → path traversal → root on EC2. To łączy software supply chain z cloud management plane. Dlatego owner tego CVE może nie być tylko Linux teamem albo AWS teamem — może być potrzebna wspólna analiza security, platform i DevOps.

Finding powinien pokazywać privilege transition

Zamiast suchego Privileges Required: Low warto pokazać: required — limited AWS SSM permission; result — root-level file write on managed host. To znacznie lepiej tłumaczy ryzyko. CVSS PR:L nie jest błędny — po prostu nie opisuje intuicyjnie przejścia między dwiema domenami uprawnień.

Wniosek

CVE-2026-81849 pokazuje, że least privilege nie jest właściwością pojedynczej policy — to właściwość całego systemu. Użytkownik może mieć ograniczone ssm:SendCommand, ale jeżeli agent wykonuje pobieranie jako root i błędnie interpretuje ścieżki, realna możliwość staje się dużo większa. Dlatego Vulnerability Engineer powinien pytać nie „jaki jest PR w CVSS?", lecz: jakie effective privilege powstaje po przejściu przez cały chain identity → cloud permission → management service → agent → host capability?

Powiązane na blogu

Read-only, a jednak root całego klastra — read-only credential, który daje roota całego klastra
Admin aplikacji czy root serwera? — inne przejście między domenami uprawnień

Źródła

AWS Security Bulletin — CVE-2026-81849 (28.08.2026) — aws.amazon.com
Amazon SSM Agent 3.3.4515.0 (release) — github.com
CVE-2026-81849 (rekord CVE) — cve.org

Nota redakcyjna: stan informacji 29 sierpnia 2026, 11:08 CEST. CVE-2026-81849 dotyczy amazon-ssm-agent przed 3.3.4515.0; Amazon przypisał CVSS 3.1 8.8 oraz CVSS 4.0 8.7. Publiczny opis nie wskazuje aktywnej eksploatacji.