Falha no AWS Kiro: Página envenenada executa código sem aviso

Imagine pedir a um assistente de código que resuma uma simples página de documentação e, em segundos, seu computador estar sob controle de um invasor. Foi exatamente isso que pesquisadores descobriram no AWS Kiro, o IDE agentivo da Amazon. Uma falha permitia que uma página web envenenada reescrevesse arquivos de configuração e executasse comandos arbitrários na máquina do desenvolvedor, sem qualquer aprovação real. O caso, revelado pela The Hacker News, expõe as entranhas de uma confiança cega em ferramentas de IA que prometem produtividade, mas entregam riscos ocultos.

Como analista de privacidade, vejo aqui um padrão perigoso: a terceirização de decisões críticas para modelos que não entendem o que estão fazendo. E o pior: a resposta oficial da AWS, embora tenha corrigido o problema, deixa perguntas incômodas sem resposta. Vamos destrinchar o que aconteceu, por que isso importa para você e como se proteger.

O ataque: texto invisível, controle total

A brecha explorava o arquivo mcp.json, onde o Kiro define quais servidores externos (Model Context Protocol) carregar e com quais comandos iniciá-los. Os pesquisadores da Intezer e Kodem Security mostraram que o Kiro podia escrever nesse arquivo usando sua própria ferramenta fsWrite, sem pedir autorização. Bastava injetar instruções escondidas em uma página web — texto branco de um pixel, invisível ao olho humano, mas perfeitamente legível para o modelo de IA.

Quando um desenvolvedor pedia ao Kiro para buscar uma URL, o agente lia o conteúdo, interpretava o bloco oculto como uma tarefa e reescrevia o mcp.json com um servidor malicioso. Em segundos, o código do invasor rodava na máquina local, com os mesmos privilégios do usuário. Na demonstração, o payload apenas exfiltrava hostname e usuário, mas poderia roubar credenciais, código-fonte ou abrir portas para a rede interna.

O mais assustador? O Kiro até exibia um pop-up de “alteração detectada”, mas recarregava a configuração independentemente do clique do usuário. A aprovação era uma farsa.

Histórico repetido: a lição que a AWS insiste em não aprender

Não é a primeira vez que o Kiro tropeça na própria autonomia. Em julho de 2025, no dia do lançamento, o pesquisador Johann Rehberger demonstrou o mesmo vetor: injeção de prompt no mcp.json. A AWS respondeu com um patch que adicionava confirmação apenas no modo Supervisionado; o modo Autopilot, padrão, continuava escrevendo o arquivo sem freios. Adivinhe qual modo a Intezer usou em 2026? O Autopilot.

Outros pesquisadores acharam variantes: escrita em .vscode/tasks.json para executar código ao abrir uma pasta (CVE-2026-10591). A AWS corrigiu, mas o ciclo se repete: promessas de segurança reativa, enquanto a raiz do problema — a confiança excessiva no julgamento do modelo — permanece.

Agora, na versão 0.11.130, o Kiro marca arquivos sensíveis como protegidos e exige aprovação explícita. Mas a pergunta que fica é: quantas outras superfícies de ataque similares ainda existem, escondidas em atualizações futuras?

O que a AWS não está contando: transparência zero

Nenhum CVE foi atribuído a essa falha. A AWS confirmou a correção via HackerOne, mas não publicou uma lista de versões afetadas, nem explicou por que a brecha não mereceu um identificador público. Para nós, que dependemos de transparência para avaliar riscos, isso é um sinal vermelho. Sem CVE, sem rastreabilidade, muitos desenvolvedores podem continuar usando versões vulneráveis sem saber.

Além disso, a AWS nunca esclareceu se o Kiro CLI ou Web compartilhavam o mesmo problema. A pesquisa cobriu apenas o IDE. Essa omissão seletiva é típica de quem prioriza a imagem corporativa em vez da segurança dos usuários.

Como profissional de privacidade, enxergo um paralelo claro com vazamentos de dados: empresas minimizam incidentes, atrasam divulgações e só agem quando pressionadas. Enquanto isso, os dados — e agora os sistemas — dos usuários ficam expostos.

Redes Wi-Fi públicas: o cenário perfeito para o desastre

Essa falha ganha contornos ainda mais graves quando pensamos no dia a dia de quem trabalha remotamente. Imagine um desenvolvedor usando o Kiro em uma cafeteria, conectado a uma rede Wi-Fi pública. Um invasor na mesma rede pode facilmente interceptar o tráfego e redirecionar uma requisição de fetch para uma página maliciosa hospedada localmente. O Kiro, obediente, leria o conteúdo e executaria o ataque — tudo sem que a vítima percebesse.

Redes Wi-Fi abertas são um prato cheio para ataques de man-in-the-middle. Sem criptografia ponta a ponta, qualquer dado trafegado pode ser capturado ou modificado. Ferramentas como o Kiro, que automaticamente buscam URLs externas, amplificam esse risco: o desenvolvedor nem precisa clicar em nada; o assistente faz o trabalho sujo sozinho.

Para se proteger:

• Nunca use IDEs agentivos ou ferramentas que executam código automaticamente em redes não confiáveis.
• Use VPN sempre que estiver fora de casa ou do escritório.
• Desabilite a execução automática de ferramentas e mantenha o modo de aprovação manual ativado.
• Monitore os arquivos de configuração do seu ambiente de desenvolvimento em busca de alterações suspeitas.

Lembre-se: o Kiro é apenas um exemplo. Qualquer ferramenta de IA que interage com a internet sem controles rígidos pode se tornar um vetor de comprometimento.

Responsabilização e o futuro da segurança em IA

O caso Kiro escancara uma verdade inconveniente: estamos delegando a agentes de IA decisões que afetam diretamente nossa segurança digital, sem garantias reais de que eles resistirão a manipulações. O modelo de segurança baseado em “humano no circuito” falha quando o circuito é burlado por um texto de um pixel.

As empresas precisam ir além de patches pontuais. É preciso arquitetar sistemas onde o controle de segurança seja externo ao modelo, imune a injeções de prompt. A AWS começou a trilhar esse caminho com os caminhos protegidos, mas a jornada está longe de terminar. Enquanto isso, nós, usuários, somos as cobaias.

Exijo transparência: divulgação completa de versões afetadas, CVEs para todas as vulnerabilidades e auditorias independentes. Sem isso, a confiança é mero marketing.

Conclusão: seus dados, suas regras

O ataque ao AWS Kiro é um alerta para todos que usam assistentes de código, chatbots ou qualquer ferramenta de IA conectada. A conveniência não pode anular a segurança. Verifique se suas ferramentas estão atualizadas, questione as permissões que você concede e, acima de tudo, monitore ativamente sua presença digital.

Na Kzarka, lutamos para que você retome o controle. Nossa plataforma monitora vazamentos de dados e alerta sobre exposições que podem ser usadas em ataques como esse. Não espere ser a próxima vítima: verifique agora se seus dados vazaram e comece a proteger sua identidade digital.

Perguntas Frequentes

O que foi a falha do AWS Kiro?

Uma vulnerabilidade permitia que uma página web maliciosa reescrevesse o arquivo de configuração do Kiro (mcp.json) e executasse código arbitrário na máquina do desenvolvedor, sem aprovação real. O ataque usava texto invisível para enganar o modelo de IA.

A AWS corrigiu o problema?

Sim, a partir da versão 0.11.130, o Kiro passou a proteger arquivos sensíveis e exigir aprovação explícita para alterações. No entanto, a AWS não divulgou um CVE nem a lista completa de versões afetadas.

Como posso saber se meus dados foram comprometidos?

Ferramentas de monitoramento de vazamentos, como a Kzarka, permitem verificar se suas credenciais ou informações pessoais circulam em bases de dados expostas. Faça uma verificação gratuita em nosso site.

Redes Wi-Fi públicas aumentam o risco desse tipo de ataque?

Sim. Em redes abertas, um invasor pode interceptar e modificar o tráfego, redirecionando o assistente de IA para páginas maliciosas. Sempre use VPN e evite executar ferramentas automáticas nesses ambientes.