AWS Kiro: quando uma página maliciosa transforma Prompt Injection em execução de código

AWS Kiro: quando uma página maliciosa transforma Prompt Injection em execução de código

A adoção de agentes de Inteligência Artificial nos ambientes de desenvolvimento está mudando rapidamente a forma como software é criado. Ferramentas capazes de analisar código, consultar documentação, modificar arquivos e executar comandos oferecem ganhos expressivos de produtividade, mas também introduzem uma questão importante para a Segurança da Informação: o que acontece quando um agente de IA com acesso ao sistema passa a seguir instruções inseridas por um atacante?

Uma vulnerabilidade identificada no Kiro, ambiente de desenvolvimento agêntico da AWS, ajuda a responder essa pergunta. Pesquisadores demonstraram que uma página web aparentemente legítima poderia conter instruções maliciosas ocultas capazes de influenciar o comportamento do agente. A partir de uma solicitação simples do desenvolvedor, como pedir que a IA resumisse aquela página, o conteúdo poderia entrar no contexto do modelo e desencadear uma cadeia que, em determinadas condições, terminaria na execução de código no computador da vítima.

O caso é associado pela AWS à CVE-2026-10591 e recebeu classificação de severidade High, com pontuação CVSS 3.1 de 8.8 no NIST/NVD. Mais do que uma vulnerabilidade específica, porém, o episódio expõe um problema estrutural da nova geração de sistemas de IA: quando modelos deixam de apenas produzir respostas e passam a executar ações, uma manipulação do contexto pode se transformar em uma ação real sobre o ambiente tecnológico.

De uma página web para o contexto da IA

O Kiro pertence a uma categoria de ferramentas significativamente diferente dos chatbots convencionais. Integrado ao ambiente de desenvolvimento, um agente desse tipo pode receber acesso a arquivos, código-fonte, comandos do sistema operacional, ferramentas externas e servidores baseados no Model Context Protocol (MCP).

Essas capacidades são justamente o que torna os agentes úteis. O desenvolvedor pode pedir que a IA investigue um problema, consulte determinada documentação, altere arquivos ou utilize ferramentas disponíveis no ambiente. Ao mesmo tempo, cada nova capacidade concedida ao agente amplia as consequências de uma eventual manipulação.

Foi exatamente esse cenário que pesquisadores da Intezer, em colaboração com a Kodem Security, exploraram.

Na demonstração apresentada pelos pesquisadores, uma página web continha documentação aparentemente legítima, mas escondia instruções maliciosas utilizando texto praticamente invisível para o usuário. O desenvolvedor não precisava baixar um executável, abrir um anexo suspeito ou copiar manualmente algum comando. Bastava solicitar ao agente algo aparentemente inofensivo, como resumir o conteúdo daquela página.

O problema é que, para o modelo, o conteúdo oculto também fazia parte das informações recebidas.

Nesse momento ocorre o chamado Indirect Prompt Injection, ou injeção indireta de prompt. Em vez de o atacante enviar diretamente uma instrução maliciosa para o agente, ele a incorpora a uma fonte externa que posteriormente será processada pela IA — uma página web, documento, e-mail, resultado de pesquisa, arquivo ou qualquer outra fonte que possa entrar no contexto do modelo.

Essa característica torna o problema particularmente relevante para agentes conectados a fontes externas. Uma informação aparentemente tratada como dado pode também ser interpretada pelo modelo como instrução.

Quando o Prompt Injection deixa de ser apenas uma resposta errada

Em um chatbot convencional, um ataque de Prompt Injection tende a afetar principalmente o comportamento do modelo: ele pode ignorar instruções previamente estabelecidas, produzir respostas inadequadas ou revelar informações que deveriam permanecer protegidas. Embora esses cenários já representem riscos relevantes, o impacto potencial aumenta significativamente quando a IA deixa de apenas gerar respostas e passa a operar como um agente capaz de executar ações no ambiente.

Esse era justamente o ponto crítico no caso do Kiro. O agente possuía capacidade para modificar arquivos no ambiente do desenvolvedor, inclusive arquivos relacionados à configuração das ferramentas que ele próprio poderia utilizar. Entre eles estava:

~/.kiro/settings/mcp.json

Esse arquivo está relacionado à configuração dos servidores Model Context Protocol (MCP) utilizados pelo Kiro. O MCP permite que aplicações e agentes de IA interajam com ferramentas, serviços e fontes externas. Dependendo da implementação e das permissões concedidas, essas integrações podem proporcionar acesso a arquivos, APIs, bancos de dados, sistemas corporativos e outras funcionalidades.

A vulnerabilidade ganhava relevância justamente nessa interação entre Prompt Injection, capacidade de escrita e execução de ferramentas. Segundo os pesquisadores, o conteúdo malicioso incorporado à página poderia influenciar o agente a modificar a configuração do MCP e adicionar um servidor controlado pelo atacante. Quando essa configuração fosse posteriormente carregada, o comando definido para inicializar o servidor poderia ser executado no computador do desenvolvedor.

Assim, uma informação inicialmente recebida como simples conteúdo externo poderia percorrer uma cadeia de ataque até produzir uma ação concreta no sistema:

Página maliciosa → instrução oculta → Indirect Prompt Injection → manipulação do agente → alteração da configuração MCP → carregamento da configuração → execução de código.

É justamente essa transição que torna o caso particularmente importante para a segurança de sistemas de IA. O ataque começa no plano da informação, com uma instrução maliciosa inserida no contexto do modelo, mas pode terminar no plano operacional, com código sendo executado no sistema da vítima.

Em outras palavras, o risco do Prompt Injection em sistemas agênticos não está apenas em fazer a IA “responder errado”. Quando o agente possui acesso a ferramentas, arquivos e recursos computacionais, manipular seu comportamento pode significar também induzir a IA a utilizar capacidades legítimas para executar ações que o usuário nunca pretendeu autorizar.

O agente estava modificando sua própria fronteira de confiança

O ponto mais crítico da vulnerabilidade não estava simplesmente na possibilidade de o Kiro modificar um arquivo. O problema estava no tipo de arquivo que o agente conseguia alterar e nas consequências dessa modificação.

O mcp.json participa da configuração dos servidores Model Context Protocol (MCP) disponíveis para o ambiente, definindo integrações que podem ampliar as capacidades do agente e estabelecer como determinadas ferramentas são inicializadas. Portanto, não se trata apenas de um arquivo de configuração comum: ele faz parte da camada que determina quais recursos externos podem ser disponibilizados ao agente e como eles podem ser acionados.

Permitir que o próprio agente modifique livremente esse tipo de configuração cria uma condição especialmente sensível. O componente que recebe instruções e executa ações passa também a influenciar os mecanismos que determinam quais ferramentas estarão disponíveis para executar essas ações.

Foi justamente esse aspecto que os pesquisadores da Intezer destacaram ao descrever o cenário como uma situação em que a IA poderia modificar sua própria trust boundary — fronteira de confiança.

O conceito vai muito além da vulnerabilidade específica do Kiro. Em arquiteturas de Agentic AI, determinados elementos precisam permanecer fora da esfera de autonomia do modelo. Políticas de segurança, ferramentas autorizadas, configurações privilegiadas, mecanismos de aprovação, arquivos capazes de provocar execução automática e controles responsáveis por estabelecer permissões devem ser protegidos por mecanismos independentes do LLM.

A razão é simples: se um agente pode ser influenciado por conteúdo não confiável e, ao mesmo tempo, possui capacidade para modificar os controles que delimitam suas próprias ações, uma falha na primeira camada pode comprometer também a segunda.

Em termos de arquitetura de segurança, portanto, o agente não deveria ter autonomia para modificar os mecanismos destinados a controlar sua própria autonomia.

Por que o Human-in-the-Loop não foi suficiente?

Uma das principais estratégias utilizadas para controlar agentes autônomos é o Human-in-the-Loop (HITL), no qual determinadas operações precisam de aprovação humana antes de serem executadas. A proposta é criar uma barreira entre aquilo que o agente pretende fazer e aquilo que efetivamente poderá acontecer no ambiente.

Em uma implementação efetiva, a sequência deveria ser:

Agente solicita uma ação sensível → execução é bloqueada → usuário recebe informações suficientes para avaliar a ação → usuário autoriza ou rejeita → somente após a autorização a operação é executada.

A ordem desses eventos é fundamental. O Human-in-the-Loop somente funciona como controle de segurança quando a autorização ocorre antes da ação e quando a decisão humana é tecnicamente capaz de impedir sua execução.

No cenário analisado pelos pesquisadores, entretanto, essa garantia poderia ser quebrada. A pesquisa descreve situações em que uma notificação era apresentada ao usuário, mas a alteração da configuração já havia ocorrido ou seu carregamento poderia acontecer independentemente da decisão posterior.

Isso evidencia uma diferença importante no projeto de sistemas agênticos:

notificar não significa autorizar.

Uma caixa de diálogo, alerta ou solicitação de confirmação não constitui, por si só, um controle de segurança. Para que o HITL seja efetivo, a arquitetura precisa estabelecer um ponto de bloqueio tecnicamente obrigatório, garantindo que nenhuma operação sensível seja concluída antes da aprovação explícita do usuário.

O controle, portanto, não pode depender apenas de o modelo decidir corretamente quando solicitar autorização. A própria camada de execução precisa impor essa autorização.

O impacto poderia ir muito além da demonstração

No Proof of Concept (PoC) apresentado pela Intezer, os pesquisadores limitaram deliberadamente o código executado. O objetivo era demonstrar a viabilidade técnica da exploração sem provocar danos ao ambiente.

Em um cenário real, entretanto, a possibilidade de executar código com os privilégios do usuário que utiliza o ambiente de desenvolvimento amplia significativamente o impacto potencial.

Estações de trabalho de desenvolvedores ocupam uma posição particularmente sensível na infraestrutura corporativa. Elas frequentemente concentram acesso a repositórios Git, código-fonte proprietário, chaves SSH, tokens de autenticação, APIs, plataformas cloud, ferramentas DevOps e pipelines CI/CD. Em alguns ambientes, também podem armazenar credenciais ou sessões autenticadas com acesso a recursos de produção.

Consequentemente, o comprometimento do agente pode representar muito mais do que a execução de um comando local. Dependendo dos privilégios disponíveis, um atacante poderia tentar utilizar o acesso inicial para obter credenciais, alcançar repositórios privados, estabelecer persistência, manipular código ou expandir o comprometimento para outros recursos da organização.

O risco, portanto, não necessariamente termina na estação do desenvolvedor. Dependendo da arquitetura e dos controles existentes, esse equipamento pode funcionar como ponto de entrada para um ataque de maior alcance, inclusive com possíveis repercussões sobre a Software Supply Chain.

Nesse contexto, o princípio do Least Privilege torna-se decisivo: o impacto de um agente comprometido estará diretamente relacionado às permissões, credenciais, ferramentas e sistemas disponíveis em seu contexto de execução.

CVE-2026-10591 e a posição da AWS

A AWS relacionou o problema reportado à CVE-2026-10591. Em seu boletim de segurança, a empresa descreve restrições insuficientes de controle de acesso na funcionalidade de escrita de arquivos do Kiro, permitindo que instruções especialmente construídas pudessem provocar gravações em caminhos considerados sensíveis à execução.

Um dos exemplos apresentados pela AWS é:

.vscode/tasks.json

Esse arquivo merece atenção porque tarefas configuradas no ambiente de desenvolvimento podem estar associadas à execução de comandos. Dessa forma, a possibilidade de modificar determinados arquivos deixa de representar apenas uma alteração de configuração e pode criar um caminho para execução de código.

O registro da vulnerabilidade no NIST National Vulnerability Database (NVD) associa a CVE à CWE-732 — Incorrect Permission Assignment for Critical Resource, com pontuação CVSS 3.1 de 8.8 (High).

Existe, entretanto, uma diferença importante entre a descrição oficial e o cenário detalhado pelos pesquisadores.

A pesquisa da Intezer concentra sua demonstração na manipulação do mcp.json e nas consequências da alteração da configuração MCP. Já o boletim da AWS descreve o problema de maneira mais abrangente, relacionado à gravação em caminhos sensíveis à execução, utilizando .vscode/tasks.json como um dos exemplos.

Essa distinção deve ser preservada. As fontes tratam de aspectos relacionados da vulnerabilidade, mas não descrevem exatamente o mesmo fluxo de exploração. O PoC envolvendo mcp.json é apresentado pela pesquisa da Intezer, enquanto a caracterização oficial da CVE deve ser atribuída à AWS e ao registro correspondente da vulnerabilidade.

O problema não está restrito a uma única vulnerabilidade

A CVE-2026-10591 também merece ser analisada dentro de um contexto mais amplo. Outros problemas de segurança relacionados ao Kiro foram divulgados ao longo de 2025 e 2026, mostrando que a proteção de ambientes de desenvolvimento agênticos envolve diferentes superfícies de ataque.

Em 2025, a AWS publicou um boletim abordando problemas de Prompt Injection no Amazon Q Developer e no Kiro, incluindo cenários nos quais conteúdo malicioso poderia interferir no comportamento esperado do agente e nos mecanismos de confirmação Human-in-the-Loop.

Em março de 2026, a CVE-2026-4295 apresentou outro vetor: projetos especialmente preparados poderiam levar à execução arbitrária de código quando abertos em versões vulneráveis do Kiro.

Posteriormente, a CVE-2026-9255 afetou o Kiro CLI e envolveu conteúdo fornecido por stdin interferindo no mecanismo de autorização utilizado para execução de ferramentas, incluindo comandos shell.

Em agosto de 2026, a AWS publicou ainda as CVE-2026-18656 e CVE-2026-18657, relacionadas ao Kiro IDE e ao Kiro CLI em ambientes Windows, envolvendo problemas na resolução de executáveis em diretórios de projetos não confiáveis.

Essas vulnerabilidades possuem causas, condições de exploração e mecanismos técnicos distintos e, portanto, não devem ser tratadas como equivalentes. Quando analisadas em conjunto, porém, ajudam a evidenciar uma questão maior: ambientes de desenvolvimento baseados em agentes combinam diversas superfícies tradicionalmente analisadas separadamente — conteúdo não confiável, execução de código, ferramentas externas, permissões locais, configurações de IDE, credenciais e interação com a cadeia de desenvolvimento de software.

Por isso, agentes de IA integrados ao desenvolvimento não deveriam ser avaliados apenas como uma nova funcionalidade da IDE. Quando possuem capacidade de agir sobre o ambiente, eles passam a constituir uma nova superfície de ataque que precisa ser incorporada ao Threat Modeling, ao Application Security e ao Secure Software Development Lifecycle (SSDLC).

A questão central deixa de ser apenas se o modelo pode ser manipulado por um Prompt Injection. Passa a ser também quais capacidades estarão disponíveis ao agente caso essa manipulação seja bem-sucedida e quais controles independentes impedirão que uma instrução maliciosa se transforme em uma ação de segurança crítica.

A correção revela um princípio importante de arquitetura

Uma das respostas ao problema foi estabelecer proteção específica para caminhos considerados sensíveis.

Configurações relacionadas ao MCP, arquivos capazes de provocar execução automática e outros elementos críticos precisam ser tratados de forma diferente de arquivos comuns do projeto.

Essa separação representa um princípio de segurança fundamental para sistemas agênticos: controles críticos precisam existir fora da esfera de decisão do modelo.

Um LLM é, por natureza, um mecanismo probabilístico. Ele pode interpretar incorretamente uma informação, ser manipulado por conteúdo externo ou simplesmente tomar uma decisão diferente daquela esperada.

Consequentemente, controles como autorização, isolamento, restrições de arquivos, validação de comandos e definição das ferramentas disponíveis devem ser implementados em camadas determinísticas.

O modelo pode solicitar uma operação.

A decisão sobre permitir essa operação precisa pertencer à camada de segurança.

O que muda para as empresas que adotam agentes de IA

A adoção de agentes de IA exige uma mudança importante na forma como as organizações avaliam o risco dessas tecnologias. Eles não deveriam ser tratados apenas como ferramentas de produtividade. Quando um agente recebe capacidade para ler e modificar arquivos, executar comandos, acessar APIs, utilizar credenciais ou interagir com sistemas corporativos, ele passa a fazer parte efetivamente da superfície de ataque da organização.

Isso significa que agentes de IA precisam ser incorporados aos processos tradicionais de Segurança da Informação, incluindo Threat Modeling, gestão de vulnerabilidades, gestão de identidades e acessos, monitoramento de segurança e Secure Software Development Lifecycle (SSDLC). O risco não deve ser avaliado apenas pelo que o modelo consegue responder, mas principalmente pelas ações que ele está autorizado a executar e pelos recursos aos quais possui acesso.

Nesse contexto, o princípio do Least Privilege (Privilégio Mínimo) torna-se ainda mais relevante. Se um agente for manipulado por meio de Prompt Injection, o impacto potencial estará diretamente relacionado às permissões disponíveis em seu contexto de execução. Um agente restrito a determinados arquivos e operações representa um risco muito diferente daquele que possui acesso ao shell, credenciais privilegiadas, repositórios de código, infraestrutura cloud e pipelines CI/CD.

O mesmo cuidado deve ser aplicado às integrações realizadas por meio do Model Context Protocol (MCP). Servidores MCP não deveriam ser adicionados indiscriminadamente apenas porque ampliam as capacidades do agente. Em ambientes corporativos, pode ser necessário estabelecer processos de homologação, listas de servidores e ferramentas autorizadas, validação das permissões solicitadas e monitoramento das alterações realizadas nas configurações.

Também é importante aumentar a visibilidade sobre o comportamento desses agentes. Processos iniciados pela IA, comandos executados, alterações em arquivos críticos, mudanças nas configurações das IDEs, modificações em servidores MCP, utilização de credenciais e interações com pipelines CI/CD são eventos que podem precisar ser registrados e monitorados de acordo com a criticidade do ambiente.

Em cenários de maior risco, mecanismos adicionais de isolamento — como containers, máquinas virtuais e sandboxes — podem limitar os recursos disponíveis ao agente e reduzir o blast radius, ou raio de impacto, caso seu comportamento seja manipulado.

A lógica de segurança, portanto, precisa evoluir de “confiar no agente para tomar a decisão correta” para “limitar tecnicamente as consequências caso o agente tome uma decisão incorreta ou seja manipulado”.

A segurança de agentes precisa considerar que o Prompt Injection pode acontecer

Essa talvez seja a principal lição deixada pelo caso do AWS Kiro.

Durante décadas, a segurança de aplicações procurou estabelecer uma separação clara entre dados e instruções executáveis. Vulnerabilidades clássicas como SQL Injection e Command Injection surgem justamente quando entradas controladas externamente conseguem atravessar essa fronteira e influenciar a execução do sistema.

Com os Large Language Models (LLMs), essa separação torna-se mais complexa. Para o modelo, linguagem natural é simultaneamente informação e mecanismo de instrução. Uma página web pode conter conteúdo legítimo que deve ser analisado e, ao mesmo tempo, instruções destinadas a modificar o comportamento da IA.

O mesmo princípio se aplica a documentos, e-mails, código-fonte, resultados de pesquisa, tickets de suporte, mensagens, bases de conhecimento e praticamente qualquer outra fonte incorporada ao contexto do agente.

Quando a IA está limitada à geração de texto, uma manipulação tende a produzir consequências dentro da própria interação. Quando o agente possui acesso a arquivos, APIs, credenciais, ferramentas, infraestrutura e comandos do sistema operacional, entretanto, uma alteração de comportamento pode se transformar em uma ação concreta sobre o ambiente.

A cadeia de risco passa então a assumir outra dimensão: Influência adversária → manipulação do comportamento do agente → utilização de uma capacidade legítima → ação não autorizada → impacto sobre o ambiente.

Essa perspectiva modifica uma das principais perguntas que as equipes de Segurança da Informação precisam fazer ao projetar ou avaliar sistemas agênticos.

Não basta perguntar: “Como impedir que alguém realize Prompt Injection contra nosso agente?”

É necessário acrescentar uma segunda pergunta, provavelmente ainda mais importante: “Se o Prompt Injection for bem-sucedido, até onde esse agente conseguirá chegar e o que estará autorizado a fazer?”

Essa mudança de perspectiva é fundamental porque desloca parte da estratégia de segurança da prevenção da manipulação do modelo para a contenção das consequências dessa manipulação.

Na prática, isso significa trabalhar com camadas independentes de proteção: privilégio mínimo, autorização determinística para ações sensíveis, segregação de funções, isolamento do ambiente, proteção de configurações críticas, controle das ferramentas disponíveis, registro das ações e monitoramento contínuo.

O modelo pode interpretar uma instrução. O agente pode solicitar uma ação. Mas a autorização para executar operações críticas não deveria depender exclusivamente da decisão probabilística do próprio modelo.

O incidente envolvendo o AWS Kiro, portanto, vai além de uma vulnerabilidade específica em uma ferramenta de desenvolvimento. Ele exemplifica um desafio estrutural que acompanha a expansão da Agentic AI: agentes estão deixando de ser sistemas que apenas produzem informações para se tornarem sistemas capazes de produzir efeitos no mundo digital.

E essa mudança exige uma premissa igualmente importante para a segurança: quanto maior a autonomia concedida ao agente de IA, mais independentes, determinísticos e robustos precisam ser os controles que limitam essa autonomia.

Referências técnicas

• The Hacker News — AWS Kiro Flaw Let a Poisoned Web Page Rewrite Its Config and Run Code
• Intezer Research — When the AI Edits Its Own Trust Boundary: Remote Code Execution Vulnerability in AWS’s Agentic IDE
• AWS Security Bulletin 2026-037 — CVE-2026-10591
• NIST National Vulnerability Database (NVD) — CVE-2026-10591
• AWS Security Bulletin AWS-2025-019 — Amazon Q Developer and Kiro Prompt Injection Issues
• AWS Security Bulletin 2026-009 — CVE-2026-4295
• AWS Security Bulletin 2026-035 — CVE-2026-9255
• AWS Security Bulletin 2026-074 — CVE-2026-18656 e CVE-2026-18657

Clique e fale com representante oficial Netwrix Endpoint Protector

Veja também:

• Pentest em Sistemas de IA
• Microsoft SharePoint sob ataque: CVE-2026-50522 permite execução remota de código e exige ação imediata
• Amatera Stealer usa blockchain para ocultar servidores C2
• Ransomware em 2026: número de vítimas bate recorde
• Top 10 Malware usados por Hackers
• O resgate não é o custo do ransomware
• Microsoft Defender pode ser transformado em arma contra EDR e antivírus
• Shadow AI: 47% do uso corporativo de IA ocorre em contas pessoais
• Cibersegurança: 95% das equipes enfrentam lacunas de habilidades
• Credenciais móveis avançam como pilar da segurança bancária
• Ransomware mira backups em 96% dos ataques
• Criminosos criam marketplace de dados pessoais para aplicar golpes na internet