Um simples conversor de arquivos de texto, o Pandoc, virou protagonista de uma história que aterroriza equipes de nuvem: invasores já exploram na vida real a vulnerabilidade CVE-2025-51591 para tentar roubar credenciais temporárias de máquinas EC2 na AWS. O achado foi detalhado pela Wiz, mesma empresa que vinha alertando sobre fraquezas do serviço de metadados da Amazon (IMDS) em aplicações mal configuradas.
Para quem cria conteúdo em WordPress hospedado na nuvem, desenvolve apps ou cuida de campanhas que dependem de infraestrutura escalável, a notícia liga um alerta vermelho. Um ataque bem-sucedido pode dar ao invasor chave-mestra para acessar S3, RDS ou qualquer serviço que a instância EC2 esteja autorizada a usar, tudo sem precisar invadir o servidor pelo shell. A brecha se apoia no clássico golpe de Server-Side Request Forgery (SSRF), mas com um twist: basta um <iframe> em um documento HTML processado pelo Pandoc para disparar a tentativa de acesso indevido.
Como o bug no Pandoc abre a porta para o IMDS
Identificada como CVE-2025-51591 (score CVSS 6,5), a falha deriva da maneira como o Pandoc renderiza <iframe>s em arquivos HTML. Um atacante envia um documento adulterado cujo atributo src aponta para o endereço reservado do IMDS (169.254.169.254). Se a aplicação que executa o Pandoc aceitar entrada do usuário sem higienização, o programa realiza a requisição localmente — exatamente o cenário perfeito para um SSRF.
O alvo principal são dois caminhos sensíveis: /latest/meta-data/iam/info e /latest/meta-data/iam/. Ambos devolvem detalhes da função IAM anexada à instância e suas credenciais temporárias. Tudo acontece sem que o atacante precise acessar o sistema operacional ou explorar vulnerabilidades mais complexas, como execução remota de código.
Por que o serviço de metadados da AWS é o alvo preferido
O IMDS foi criado para facilitar a vida dos desenvolvedores: em vez de gravar chaves fixas no disco, a aplicação consulta esse endpoint e recebe tokens de curta duração, reduzindo exposição acidental. O problema é que a primeira versão do protocolo (IMDSv1) responde a qualquer requisição vinda da própria instância, sem exigir autenticação adicional.
Essa simplicidade transforma vulnerabilidades de SSRF em pontes diretas para o roubo de credenciais. Historicamente, já vimos o grupo UNC2903 abusar de uma falha no Adminer (CVE-2021-21311) para acessar IMDS e exfiltrar dados em 2021. Mais recentemente, a Resecurity classificou ataques desse tipo como de “consequências severas e de longo alcance”, pois o tráfego parte de dentro da nuvem, driblando firewalls de perímetro e listas de IPs confiáveis.
O que aconteceu nos ataques observados
A Wiz detectou tentativas reais desde agosto e por algumas semanas seguidas. Os invasores enviaram documentos maliciosos, mas se depararam com um obstáculo: a adoção do IMDSv2. Diferente da versão anterior, o IMDSv2 exige que o cliente peça um token, usando o cabeçalho X-aws-ec2-metadata-token em todas as requisições subsequentes, bloqueando a interação automática do <iframe>.
Imagem: Internet
Além do Pandoc, os pesquisadores notaram esforços paralelos para abusar de outra falha de SSRF no banco analítico ClickHouse, desta vez mirando nuvens Google Cloud — também sem sucesso graças a configurações mais rígidas.
Para mitigar o risco específico do Pandoc, os mantenedores orientam duas alternativas: rodar o programa com o parâmetro -f html+raw_html ou acionar --sandbox, que impede a resolução do src em <iframe>. A equipe do Pandoc ressalta que renderizar iframes é comportamento normal, colocando sobre o usuário a responsabilidade de filtrar entradas não confiáveis.
Mais que um iframe: por que a segurança de nuvem depende de boas configurações
A história reforça uma lição que vai além do Pandoc: vulnerabilidades medianas — um CVSS 6,5 normalmente não causa alvoroço — podem virar porta de entrada crítica quando encontram combinações perigosas na nuvem. Aqui, um conversor de documentos se uniu ao IMDSv1 para criar um vetor silencioso de exfiltração.
Do ponto de vista operacional, quem gerencia blogs, lojas virtuais ou stacks de marketing em EC2 deve revisar três frentes: (1) migrar para IMDSv2 e rejeitar qualquer exceção, (2) limitar permissões IAM ao estritamente necessário (Princípio do Menor Privilégio) e (3) tratar qualquer aplicativo que processe entrada do usuário — mesmo “inofensivo” como um conversor de Markdown — como potencial vetor de SSRF.
No fim, a nuvem não falhou; a configuração falhou. A boa notícia é que a migração para IMDSv2, aliada a filtros de entrada e atualização de bibliotecas, bloqueia o ataque demonstrado. A má é que, enquanto existirem instâncias legadas ou scripts que ainda dependem do IMDSv1, o mercado continuará no jogo de gato e rato. Entender a mecânica por trás desses incidentes é o melhor antídoto contra a próxima vulnerabilidade aparentemente banal que aparecer no radar.
