Ferramentas de desenvolvimento com IA como Cursor, Windsurf e Copilot podem ser causadas, via injeção imediata e funções “normais” do IDE, ler segredos e executar comandos sem que o usuário perceba — é isso que a pesquisa IDEsaster expõe.
A classe de vulnerabilidades do IDEsaster
O pesquisador Ari Marzouk (MaccariTA) acordou 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 – todos explorando o mesmo padrão: prompt injector + 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, alterar configurações, chamar ferramentas MCP, executar comandos), qualquer instrução maliciosa que entre no contexto – em código, README, JSON, URLs, MCP, etc.
Como os ataques são encadeados
Os vetores descritos são:
- Seqüestro de contexto / injeção imediata: instruções escondidas em comentários, strings, nomes de arquivos, URLs, documentos 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 configuração,
.vscode/settings.json,.idea/workspace.xmlou configurações próprias do agente, sem pedir autorização ao desenvolvedor. - Uso de recursos legítimos do IDE: a partir daí, o agente passa a ler arquivos sensíveis (chaves,
.envsegredos), escrever JSONs que apontam para esquemas remotos em domínio do invasor (forçando a IDE a buscar e enviar dados), alterar caminhos de ocorrências possíveis (comophp.validate.executablePath,PATH_TO_GIT) para binários maliciosos, ou editar a configuração 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 relacionados: Codex CLI, Gemini, PromptPwnd
A pesquisa conecta essas ideias a outros achados recentes:
- CLI do OpenAI Codex (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 configuração maliciosos já bastava para rodar código na máquina do dev.
- CLI do Google Gemini: Vulnerabilidades demonstradas a prompt de injeções indiretas após o lançamento, permitindo proteção de credenciais ou inserção de backdoors quando o agente lia artefatos controlados por atacantes.
- PromptPwnd em agentes de CI/CD: Mostrar como agentes de IA integrados a pipelines com privilégios elevados podem ser induzidos, via instruções em PRs, YAMLs ou logs, para executar ações privilegiadas (merge, deploy, alteração de políticas), 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 desenvolvedores e tempos de segurança
- Usando AI‑IDEs apenas em projetos confiáveis: evite rodar agentes de IA em repositórios desconhecidos, fork recém‑clonado ou código de terceiros sem revisão.
- Auditar fontes de contexto: executar 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: desabilita ações automáticas perigosas (edição de configurações, execução de comandos, alteração de configurações), exigência de permissão explícita para mudanças em arquivos de build, scripts, pipelines e configurações de agente.
- Endurecer solicita sistema e sandbox: aplique “prompts do sistema” que reforcem limites (por exemplo, nunca execute comandos nem envie arquivos externos sem confirmação), use sandboxes ou containers para qualquer ação de escrita/execução sugerida pelo agente e testar especificamente contra fuga de caminho, vazamento de dados e injeção de comando.
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.
