Uma falha de alta gravidade no Amazon Q Developer, rastreada como CVE-2026-12957, permitia que um repositório malicioso roubasse credenciais da AWS no instante em que um programador o abria — sem clique, sem aviso, sem consentimento. A Amazon corrigiu o problema em maio e divulgou o boletim público nesta sexta-feira, 26 de junho de 2026. Não há evidências de exploração real, mas o caso expõe um risco sistêmico em assistentes de código com inteligência artificial.

Pesquisadores da Wiz Research descobriram que a extensão do Amazon Q carregava automaticamente configurações de servidores MCP (Model Context Protocol) embutidas em qualquer workspace, sem pedir permissão ao usuário. Bastava clonar e abrir o código comprometido para que comandos controlados pelo atacante rodassem em segundo plano, com acesso total às credenciais de nuvem da vítima.

Como a falha funcionava por dentro

O Amazon Q Developer é o assistente de programação com IA da Amazon, concorrente direto do GitHub Copilot. Ele sugere código, faz refatoração automática e se conecta a ferramentas externas por meio de servidores MCP — um protocolo que permite à IA acessar fontes de dados e executar processos locais. A vulnerabilidade estava justamente aí.

Quando um desenvolvedor abria um repositório, a extensão lia um arquivo chamado .amazonq/mcp.json e registrava e iniciava o servidor MCP definido nele sem qualquer etapa de confirmação. Esse processo herdava o ambiente completo do programador, incluindo variáveis sensíveis. Segundo o Cyber Security News, um único arquivo malicioso conseguia exfiltrar credenciais ativas de sessão da AWS para um servidor controlado pelo atacante.

A Wiz publicou uma prova de conceito que rodava um comando padrão de identidade da AWS pelo servidor MCP fraudulento e enviava o resultado para fora — número da conta, ARN do usuário e tokens de sessão. Tudo isso sem prompts, sem cliques e sem qualquer alerta visível, conforme detalhou o TNW.

O que os atacantes conseguiam roubar

Como os processos gerados pela falha herdam todo o ambiente do desenvolvedor, o alcance do ataque é amplo. Os dados expostos incluíam:

  • AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY e AWS_SESSION_TOKEN — credenciais que abrem portas para qualquer serviço da nuvem;
  • Tokens de autenticação de CLIs de provedores de nuvem;
  • Chaves de API e secrets armazenadas em variáveis de ambiente;
  • Sockets do agente SSH, possibilitando acesso a servidores privados.

Programadores autenticados na AWS no momento da abertura do repositório eram os alvos mais valiosos, pois suas credenciais de sessão ativa podiam ser capturadas e exfiltradas sem aviso. A combinação de execução automática, criação de processos shell e herança de ambiente criou uma vulnerabilidade de alta gravidade numa ferramenta usada por milhões de desenvolvedores, segundo a Wiz.

Versões afetadas e correção disponível

A Amazon atribuiu dois CVEs ao problema: CVE-2026-12957, por impor limites de confiança inadequados e executar configurações MCP sem consentimento; e CVE-2026-12958, por falta de validação de symlinks, permitindo escrita de arquivos arbitrários fora do workspace. A tabela abaixo resume as versões afetadas e a correção:

Produto Versão vulnerável Correção
Language Servers for AWS anterior a 1.69.0 1.69.0 ou superior
Amazon Q Developer para VS Code anterior a 2.20 2.20 ou superior
Amazon Q Developer para JetBrains anterior a 4.3 4.3 ou superior
Amazon Q Developer para Eclipse anterior a 2.7.4 2.7.4 ou superior
AWS Toolkit com Amazon Q (Visual Studio) anterior a 1.94.0.0 1.94.0.0 ou superior

O Language Server da AWS atualiza automaticamente na maioria dos casos; basta recarregar a IDE para disparar a atualização. A Amazon agora exige aprovação explícita do usuário antes de iniciar qualquer servidor MCP e restringe as variáveis de ambiente que esses servidores podem acessar. O boletim completo foi publicado como Security Bulletin 2026-047-AWS.

Cenários de ataque para devs brasileiros

Os pesquisadores da Wiz listaram três vetores práticos que funcionam contra qualquer desenvolvedor — inclusive os do Brasil, onde o uso da AWS é massivo entre startups e grandes empresas:

  1. Pull requests maliciosos em projetos open source populares: o atacante contribui com código que inclui um .amazonq/mcp.json escondido; quem revisa ou clona o repositório dispara a captura de credenciais.
  2. Pacotes typosquatted: nomes parecidos com bibliotecas conhecidas, que embutem configurações MCP maliciosas.
  3. Testes de código em entrevistas falsas: tática já usada por hackers ligados à Coreia do Norte, em que o candidato recebe um repositório para clonar e executar.

Esse último cenário é especialmente perigoso porque explora a pressão e a confiança do candidato, que raramente audita o que abre antes de rodar. O mesmo padrão de confiança em repositórios já rendeu problemas em pipelines de CI/CD, como mostramos ao analisar o caso Cordyceps, que expôs milhões de repositórios a invasão por falhas de automação.

Risco que vai além da Amazon

A Wiz alertou que o problema subjacente não é exclusivo do Amazon Q. Outros pesquisadores já identificaram falhas semelhantes em ferramentas concorrentes de IA para código. A Check Point Research documentou as vulnerabilidades CVE-2025-59536 e CVE-2026-21852 no Claude Code, da Anthropic, e a OX Security encontrou a CVE-2026-30615 no Windsurf, da Codeium — todas derivadas do mesmo risco de autoexecução.

O protocolo MCP, por definição, dá aos assistentes de IA a capacidade de chamar ferramentas externas com as permissões da aplicação hospedeira. Quando um repositório consegue registrar silenciosamente um servidor MCP que herda as credenciais de nuvem do desenvolvedor, a superfície de ataque salta do próprio código para todos os serviços acessíveis por aquela conta. O tema da segurança em MCP também já havia sido sinalizado em nosso material sobre firewalls de aplicação testados via MCP, onde a confiança excessiva no protocolo abre vetores inesperados.

Como se proteger agora

Apesar de a Amazon não ter encontrado evidências de exploração ativa, a recomendação é atualizar imediatamente todos os plugins do Amazon Q Developer e revisar repositórios clonados recentemente. As medidas práticas incluem:

  • Atualizar todos os plugins do Amazon Q para as versões corrigidas listadas acima;
  • Tratar repositórios desconhecidos ou não verificados como não confiáveis;
  • Inspecionar diretórios .amazonq/ em repositórios clonados antes de abri-los;
  • Avaliar com atenção os novos prompts de consentimento de servidor MCP antes de aprovar execução;
  • Usar credenciais de menor privilégio e rotacionar chaves de acesso regularmente, limitando o dano de um vazamento.

Ferramentas de desenvolvimento seguem sendo alvo recorrente de atacantes. O episódio lembra o que vimos nas 26 falhas corrigidas em plugins do Jenkins, onde o bypass de sandbox em ferramentas de CI/CD criava caminhos para execução remota de código. Em ambos os casos, a lição é a mesma: toda configuração que dispara execução de código no momento da clonagem é uma arma, e a ferramenta que a executa automaticamente é quem mantém o seguro destravado.

Referências