Falha no agente do AWS Systems Manager permite contornar restrições de encaminhamento
A Amazon corrigiu uma vulnerabilidade de segurança no agente do AWS Systems Manager que pode permitir que usuários autenticados escapem das limitações aplicadas ao encaminhamento de portas. Registrada como CVE-2026-89049, a falha afeta versões antigas do componente instalado em instâncias da AWS e pode expor credenciais temporárias com permissões do ambiente.
O problema está relacionado ao Session Manager, recurso usado para administrar instâncias sem a necessidade de abrir portas de entrada ou manter servidores de acesso remoto tradicionais. Entre suas funções está o encaminhamento de conexões para serviços externos ou internos, sempre com regras destinadas a impedir o acesso indevido a endereços sensíveis.
Para bloquear esse tipo de abuso, o agente do Systems Manager mantém uma lista de endereços link-local que não deveriam ser alcançados por meio de sessões de encaminhamento. Entre eles está o endereço 169.254.169.254, utilizado pelo serviço de metadados das instâncias EC2.
Esse serviço é especialmente importante porque pode fornecer informações temporárias associadas ao perfil IAM atribuído à máquina. Quando o perfil possui permissões amplas, a obtenção dessas credenciais pode permitir que o invasor consulte serviços da AWS, altere recursos ou acesse dados sem precisar permanecer diretamente conectado à instância comprometida.
Como a vulnerabilidade funciona
A falha não está na ausência de uma regra de bloqueio, mas na forma como o agente valida o endereço informado. O software reconhece determinadas representações do endereço proibido, porém não trata corretamente formatos alternativos que apontam para o mesmo destino.
Assim, um atacante autenticado pode utilizar uma variação equivalente do endereço bloqueado para enganar o mecanismo de filtragem. A verificação deixa de identificar o destino como pertencente à faixa protegida, permitindo que a sessão seja estabelecida contra o serviço de metadados.
Depois de obter as credenciais temporárias, o invasor pode realizar chamadas à API da AWS a partir de outro local. O impacto dependerá diretamente das permissões concedidas ao papel IAM da instância. Funções com privilégios excessivos ampliam o risco e podem transformar uma falha localizada em um incidente envolvendo vários recursos da conta.
A vulnerabilidade afeta o agente em versões anteriores à 3.3.4851.0. A correção foi incorporada à versão 3.3.4851.0 e permanece disponível nas edições posteriores.
Atualização deve ser prioridade
A principal medida recomendada é atualizar o agente do AWS Systems Manager em todas as instâncias afetadas. A instalação deve ser validada também em ambientes de teste, imagens personalizadas, grupos de Auto Scaling, pipelines de CI/CD e máquinas criadas automaticamente, pois uma instância nova pode voltar a utilizar uma versão vulnerável se a imagem de origem não tiver sido atualizada.
Organizações que mantêm versões modificadas ou builds derivados do agente devem revisar o código e incorporar as correções correspondentes. Apenas atualizar parte da infraestrutura não é suficiente quando imagens antigas continuam sendo utilizadas na criação de novas máquinas.
Também é recomendável controlar cuidadosamente quem pode executar o documento AWS-StartPortForwardingSessionToRemoteHost. O acesso a esse recurso deve ser concedido somente a operadores que realmente necessitam dele, preferencialmente com políticas específicas, registros detalhados e aprovação para atividades de maior risco.
Revisão das permissões IAM
A exploração da falha depende, em grande medida, das permissões atribuídas à instância. Por isso, a revisão dos papéis IAM deve fazer parte da resposta. Cada máquina deve possuir apenas os acessos necessários para executar sua função, sem permissões genéricas ou abrangentes que não sejam justificadas.
A remoção de ações administrativas desnecessárias reduz o impacto mesmo quando credenciais temporárias são expostas. Também é importante avaliar políticas anexadas diretamente ao papel, permissões herdadas de grupos e eventuais regras que permitam acesso a serviços críticos, como armazenamento, bancos de dados, gerenciamento de chaves e recursos de identidade.
Credenciais obtidas pelo serviço de metadados podem ter duração limitada, mas isso não elimina o risco. Um invasor pode utilizá-las rapidamente para coletar informações, criar persistência, alterar configurações ou iniciar novas ações com outros recursos da conta.
Monitoramento e investigação
A AWS recomenda auditar os registros de atividade do Session Manager para identificar sessões de encaminhamento incomuns. Devem ser analisados horários, usuários responsáveis, instâncias envolvidas, destinos acessados e frequência das conexões.
Sinais como sessões abertas fora do expediente, uso por contas que normalmente não administram servidores, acessos repetidos a destinos internos ou comandos executados a partir de máquinas inesperadas merecem investigação. A comparação com o comportamento habitual dos administradores pode ajudar a encontrar desvios.
Os registros de chamadas à API também devem ser examinados em busca de uso das credenciais temporárias. Mudanças em políticas IAM, criação de usuários, alteração de grupos de segurança, leitura de buckets, geração de chaves ou implantação de novas instâncias podem indicar que as credenciais foram abusadas.
Medidas adicionais de proteção
Além da atualização, as equipes podem reforçar a proteção do ambiente adotando controles complementares:
– manter o acesso ao IMDS protegido e, quando possível, exigir o IMDSv2;
– evitar permissões administrativas em papéis de instâncias;
– limitar o uso de encaminhamento de portas a redes e usuários autorizados;
– revisar regularmente documentos e políticas do Systems Manager;
– centralizar logs de administração e configurar alertas para eventos anormais;
– atualizar imagens de máquinas e agentes de gerenciamento de forma automatizada;
– separar contas e ambientes de produção, testes e desenvolvimento;
– utilizar políticas de negação explícita para bloquear operações de alto impacto quando necessário.
A vulnerabilidade demonstra que filtros baseados apenas em texto podem falhar quando diferentes formatos representam o mesmo endereço de rede. Por isso, mecanismos de segurança devem normalizar e validar os destinos antes de aplicar regras de bloqueio.
Mesmo com a correção instalada, as empresas devem verificar se houve exploração anterior. A atualização impede novas tentativas por meio da falha, mas não revoga automaticamente credenciais que possam ter sido acessadas. Caso existam indícios de comprometimento, é necessário substituir credenciais, revisar permissões, investigar atividades na conta e avaliar recursos criados ou modificados durante o período de exposição.