CVE-2026-89049 no AWS SSM Agent: falha de SSRF pode expor credenciais IAM

Uma vulnerabilidade no AWS Systems Manager Agent mostra como um recurso criado para administração segura pode se transformar em um caminho indireto para recursos internos da instância. O problema afeta o port forwarding do Session Manager e pode permitir que um usuário autorizado abuse do agente como proxy SSRF para alcançar serviços locais, inclusive o Instance Metadata Service da AWS.

O que está por trás da CVE-2026-89049

A falha, identificada como CVE-2026-89049, está associada ao Amazon SSM Agent, componente instalado em instâncias EC2 e outros sistemas gerenciados pelo AWS Systems Manager. Segundo a divulgação técnica que motivou o alerta, o comportamento vulnerável aparece no recurso de encaminhamento de portas do Session Manager, que permite estabelecer conexões a partir de uma sessão administrativa sem expor diretamente SSH ou RDP à Internet.

O ponto crítico é a diferença entre permitir uma conexão administrativa controlada e permitir que o agente alcance destinos escolhidos pelo usuário dentro do próprio contexto de rede da instância. Quando esse segundo comportamento não restringe adequadamente endereços sensíveis, surge uma condição de Server-Side Request Forgery, ou SSRF.

Como o abuso pode alcançar o serviço de metadados

Em uma exploração desse tipo, o atacante não precisa necessariamente comprometer primeiro o sistema operacional da instância. Um usuário que já possua permissões suficientes para iniciar determinadas sessões do Systems Manager pode solicitar o encaminhamento de tráfego para endereços acessíveis localmente pela máquina gerenciada.

Entre esses destinos está o Instance Metadata Service, normalmente disponível no endereço link-local 169.254.169.254. O serviço fornece metadados necessários à operação da instância e, quando uma IAM Role está associada ao EC2, pode disponibilizar credenciais temporárias usadas por aplicações e agentes para acessar APIs da AWS.

Isso transforma o problema em algo maior do que uma simples falha de conectividade. Se as credenciais recuperadas possuírem permissões relevantes, o impacto passa a depender da política IAM associada à instância. Em ambientes com privilégios excessivos, uma vulnerabilidade inicialmente localizada pode contribuir para descoberta de recursos, acesso a dados, movimentação lateral na conta cloud e execução de ações adicionais por meio das APIs da AWS.

Por que a identidade da instância define o impacto real

A vulnerabilidade reforça um princípio importante de segurança em nuvem: o risco técnico de uma falha não pode ser avaliado isoladamente da identidade que o workload utiliza. Duas instâncias vulneráveis podem produzir impactos completamente diferentes se uma possuir uma role estritamente limitada e a outra tiver permissões amplas sobre S3, Secrets Manager, KMS, bancos de dados, funções Lambda ou recursos administrativos.

Por isso, equipes de segurança devem tratar a correção do agente e a revisão das permissões IAM como ações complementares. Atualizar o software reduz a superfície de exploração; aplicar least privilege limita o raio de impacto caso uma vulnerabilidade semelhante volte a surgir.

Notícias Relacionadas

Ataques em velocidade de IA reduzem a janela de defesa

Gateways de IA ampliam a superfície crítica de segurança

PostGREShell: vulnerabilidade crítica reforça a urgência do patching

O que as equipes de segurança devem verificar

A primeira medida é identificar as versões do Amazon SSM Agent existentes no ambiente e aplicar a versão corrigida indicada pela AWS. Em organizações com grande quantidade de workloads, o inventário deve incluir EC2, servidores híbridos e imagens ou templates que possam reinstalar versões antigas posteriormente.

Também é recomendável revisar quem pode iniciar sessões do AWS Systems Manager e, especialmente, utilizar documentos e modalidades de port forwarding. Permissões como ssm:StartSession não devem ser tratadas como um simples substituto de SSH: elas representam uma capacidade administrativa poderosa e precisam ser governadas por identidade, função, contexto e necessidade operacional.

Outra camada importante é reforçar o uso do IMDSv2 e revisar configurações que ainda aceitem mecanismos legados de acesso ao serviço de metadados. O IMDSv2 utiliza tokens de sessão e foi projetado para elevar a resistência a diversas classes de abuso relacionadas a SSRF, embora sua adoção não substitua a atualização do componente vulnerável nem a aplicação de controles IAM adequados.

Logs do CloudTrail, registros do Systems Manager e telemetria das instâncias também devem ser correlacionados para identificar sessões administrativas inesperadas, uso incomum de port forwarding e chamadas posteriores às APIs da AWS feitas com credenciais vinculadas às roles das instâncias.

O problema também é de governança cloud

Para o negócio, o episódio evidencia uma fragilidade recorrente em arquiteturas cloud: ferramentas de administração concentram privilégios e conectividade justamente porque precisam simplificar operações. Quando essas capacidades não são inventariadas, monitoradas e submetidas a controles de mínimo privilégio, uma falha em um agente confiável pode atravessar fronteiras entre administração de servidores e identidade cloud.

Programas de Cloud Security Posture Management, revisões periódicas de IAM, gestão de vulnerabilidades e hardening de imagens devem, portanto, considerar agentes de gerenciamento como parte da superfície crítica. O mesmo raciocínio vale para agentes de observabilidade, backup, EDR, automação e configuração: quanto maior o nível de acesso técnico do componente, maior deve ser a disciplina sobre atualização, configuração e telemetria.

Conclusão

A CVE-2026-89049 demonstra que eliminar portas administrativas expostas é apenas uma parte da proteção de workloads em nuvem. O Session Manager reduz riscos importantes associados a SSH e RDP públicos, mas continua sendo um canal privilegiado e deve ser protegido como tal. A resposta mais consistente combina atualização rápida do SSM Agent, IMDSv2, mínimo privilégio nas roles de instância, controle rigoroso sobre StartSession e monitoramento contínuo das atividades administrativas.