Ferramentas de desenvolvimento com IA como Cursor, Windsurf e Copilot podem ser induzidas, via prompt injection e funções “normais” do IDE, a ler segredos e executar comandos sem que o usuário perceba — é isso que a pesquisa IDEsaster expõe.
A classe de vulnerabilidades IDEsaster
O pesquisador Ari Marzouk (MaccariTA) identificou mais de 30 falhas em IDEs e assistentes com IA – incluindo Cursor, Windsurf, Kiro.dev, GitHub Copilot, Zed.dev, Roo Code, Junie, Claude Code e Cline – todas explorando o mesmo padrão: prompt injection + ações automáticas do agente + APIs legítimas da IDE. Em 24 desses casos já existem CVEs, e em testes o mesmo encadeamento de ataque funcionou em 100% das ferramentas avaliadas.
A ideia central é que, quando o agente de IA está autorizado a tomar decisões sozinho (editar arquivos, mudar settings, chamar ferramentas MCP, executar comandos), qualquer instrução maliciosa que entre no contexto – em código, README, JSON, URLs, MCP, etc. – pode transformar capacidades normais da IDE em vetor de exfiltração ou RCE.
Como os ataques são encadeados
Os vetores descritos combinam:
- Hijack de contexto / prompt injection: instruções escondidas em comentários, strings, nomes de arquivos, URLs, docs externos, ou injeções via Model Context Protocol (MCP) e ferramentas que consomem dados de fontes controladas pelo atacante.
- Ações auto‑aprovadas: muitos agentes aceitam “sim” sozinhos para editar arquivos de projeto, JSONs de config,
.vscode/settings.json,.idea/workspace.xmlou configs próprias do agente, sem pedir confirmação ao desenvolvedor. - Uso de recursos legítimos da IDE: a partir daí, o agente passa a ler arquivos sensíveis (chaves,
.env, secrets), escrever JSONs que apontam para schemas remotos em domínio do invasor (forçando a IDE a buscar e enviar dados), alterar paths de executáveis (comophp.validate.executablePath,PATH_TO_GIT) para binários maliciosos, ou editar a config MCP para iniciar um servidor stdio que executa comandos arbitrários.
O resultado prático inclui vazamento de segredos, modificação de build/config, criação de backdoors persistentes em repositórios e execução remota de código no ambiente de desenvolvimento – tudo disparado por “apenas seguir instruções” vistas pelo LLM como contexto legítimo.
Casos correlatos: Codex CLI, Gemini, PromptPwnd
A pesquisa conecta essas ideias a outros achados recentes:
- OpenAI Codex CLI (CVE‑2025‑61260): o CLI carregava configurações MCP de pastas de projeto e executava comandos definidos ali automaticamente na inicialização, sem confirmação; clonar um repositório com arquivos de config maliciosos já bastava para rodar código na máquina do dev.
- Google Gemini CLI: demonstrou vulnerabilidades a prompt injections indiretos logo após o lançamento, permitindo extração de credenciais ou inserção de backdoors quando o agente lia artefatos controlados por atacantes.
- PromptPwnd em agentes de CI/CD: mostra como agentes de IA integrados a pipelines com privilégios elevados podem ser induzidos, via instruções em PRs, YAMLs ou logs, a executar ações privilegiadas (merge, deploy, alteração de policies), ampliando muito o impacto.
Esses exemplos reforçam a tese de que agentes de IA não distinguem “ordens” do usuário de instruções maliciosas embutidas em dados, o que torna todo o fluxo de contexto parte da superfície de ataque.
Recomendações práticas para devs e times de segurança
- Usar AI‑IDEs apenas em projetos confiáveis: evitar rodar agentes de IA em repositórios desconhecidos, fork recém‑clonado ou código de terceiros sem revisão.
- Auditar fontes de contexto: inspecionar arquivos de configuração, README, comentários extensos, URLs e ferramentas MCP em busca de instruções escondidas; conectar apenas a servidores MCP confiáveis e monitorar alterações nesses serviços.
- Limitar poderes do agente: desabilitar ações automáticas perigosas (edição de configs, execução de comandos, alteração de settings), exigir confirmação explícita para mudanças em arquivos de build, scripts, pipelines e configs de agente.
- Endurecer prompts de sistema e sandbox: aplicar “system prompts” que reforcem limites (por exemplo, nunca executar comandos nem enviar arquivos externos sem confirmação), usar sandboxes ou containers para qualquer ação de escrita/execução sugerida pelo agente e testar especificamente contra fuga de path, vazamento de dados e command injection.
Marzouk argumenta que tudo isso aponta para uma nova disciplina de segurança “Secure for AI”: não apenas proteger modelos, mas projetar todo o ciclo de vida de produtos assumindo que agentes de IA serão alvo e ferramenta em cadeias de ataque.