Traduzido do 日本語 • Ver original 
Nos últimos anos, o desenvolvimento adotou rapidamente ferramentas de completação de código e automação baseadas em IA para melhorar a produtividade. Cursor, Copilot e vários IDEs baseados em LLM não são mais apenas para algumas equipes avançadas, mas se tornaram ferramentas do dia a dia para muitas organizações de desenvolvimento.
No entanto, você sabia que por trás dessa "conveniência" há uma nova superfície de ataque que ainda não existia no ambiente de desenvolvimento?
Neste blog, discutiremos as vulnerabilidades críticas identificadas no editor de código de IA Cursor .
"Execução Remota de Código (RCE) Abusando das Configurações MCP (Protocolo de Contexto de Modelo)"
――Vamos organizar e explicar o mecanismo, o fluxo de ataque, os riscos e as contramedidas práticas do MCPosion (CVE-2025-54136), comumente conhecido como MCPosion .
Resumo da Ameaça: As "Configurações Confiáveis" da IA se tornam o ponto de partida dos ataques
A essência dessa vulnerabilidade está no próprio "modelo de confiança" que o Cursor emprega.
O Cursor usa MCP (Model Context Protocol) como um mecanismo para a IA manipular ferramentas externas.
Os desenvolvedores podem definir '.cursor/rules/mcp.json' para cada projeto, que pode incluir informações como:
- Nome MCP
- Comandos a serem executados
- Argumentos (parâmetros)
Quando o Cursor abre um projeto, ele escaneia automaticamente esse diretório '.cursor' e processa os MCPs definidos.
O problema começa aqui.
Uma vez que o usuário reconhece que "confio neste MCP",
**A partir de agora, as decisões de confiança são tomadas apenas com base no "nome", e mudanças nos comandos de execução ou argumentos não são mais verificadas. **
Ao abusar desse comportamento,
Se você substituir por um comando malicioso depois, ele será executado sem aprovação adicional
Uma condição séria nasce.
Ataque Flow: "Colaboração Comum" no GitHub Vira uma Armadilha
Os ataques do MCPosion ocorrem de forma muito realista e silenciosa.
Você não precisa de servidores especiais vulneráveis ou serviços públicos.
O **curso do ataque é o seguinte: **
1. Intrusão Inicial: Um Compromisso Aparentemente Inofensivo
O atacante usa o
Faça um commit que contenha uma configuração MCP aparentemente boa .
- Não inclui comandos maliciosos
- Parece uma definição normal de ferramenta
- Menos suspeito ao revisar
Neste momento, o dano ainda não ocorrerá.
2. Aprovação do projeto no Cursor
Quando a vítima (desenvolvedora) abre o projeto em Cursor,
Um diálogo de confirmação para o novo MCP vai aparecer: "Você quer permitir que ele funcione?"
Aqui, quando o usuário aprova,
O nome MCP é registrado como status de Trust .
3. Injeção de Cargas Maliciosas
O atacante pode usar o
**Substitua apenas os "comandos de execução" e "argumentos" do MCP que já são confiáveis. **
- Sem mudança no nome MCP
- No entanto, o conteúdo da execução é completamente diferente
- Cursor não pede reaprovação
Esse é o cerne dessa vulnerabilidade.
4. Execução de Exploit: RCE apenas com sincronização e reinício
O ataque é estabelecido no momento em que a vítima faz qualquer uma das seguintes ações:
- Sincronizar repositórios (puxar)
- Reiniciar cursor
Como resultado,
Comandos maliciosos são executados imediatamente com privilégios de usuário .
Estudos também confirmaram o controle completo do sistema usando a Reverse Shell.
Por Que É Perigoso: Quebrando Pressupostos Tradicionais de Segurança
O que torna esse problema sério é que não é apenas um "bug de ferramenta".
Suposições Tradicionais
- Repositórios do GitHub são revisados
- Código executado localmente é por sua conta e risco
- IDE é uma "ferramenta passiva"
A realidade que MCPosion enfrentou
- O arquivo de configuração torna-se o sujeito da execução.
- IA executa comandos automaticamente
- "One trust" permite mudanças futuras
Em outras palavras,
O próprio ambiente de desenvolvimento assistido por IA se torna um vetor de ataque
Um novo modelo de ameaça foi exposto.
Dificuldade de Detecção: Sem registros ou alertas restantes
Esse ataque é muito difícil de detectar pelos seguintes motivos:
- Operações canônicas do GitHub (commit/pull)
- Comportamento canônico do cursor
- MCP aprovado pelo próprio usuário
Mesmo do ponto de vista da EDR e antivírus,
Na maioria dos casos, parece que "o desenvolvedor apenas usou a ferramenta".
Contramedida: Não "confie demais no ambiente de desenvolvimento de IA"
1. Atualização do Cursor (Prioridade Máxima)
Essa vulnerabilidade foi corrigida na versão mais recente .
Para ambientes que usam Cursor, atualizações rápidas são fortemente recomendadas.
2. Direcionando configurações MCP para revisão de código
- Revise '.cursor/' como se fosse código normal
- Não apenas o "nome" do MCP
Requer verificação de diferenças de comandos e argumentos de execução
3. Minimizar os privilégios das ferramentas de IA
- Evite usar privilégios de administrador em terminais de desenvolvimento
- Limitar o escopo de influência dos comandos executados por meio de ferramentas de IA
4. Redefinindo "confiança"
- Não assuma o design de que uma aprovação = trust permanente
- Declarar claramente a política de uso da ferramenta de IA dentro da equipe
Conclusão: IA é poderosa, mas não neutra
MCPosion
Esta não é uma história em que "usar IA em si é perigoso".
O problema é,
A razão é que os "limites de confiança" que os humanos construíram foram trazidos diretamente para o fluxo de trabalho da era da IA.
IA escreve código,
IA alimenta ferramentas,
A IA interpreta as configurações e
E — a IA também pode ser um vetor de ataque.
Agora é a hora,
"O que a IA pode fazer, até que ponto e com autoridade de quem?"
É hora de perguntar de novo.
Eficiência no desenvolvimento e segurança não são concessões.
Se você projetar direito, pode fazer os dois.
Esperamos que este blog inspire você a revisar seu ambiente de desenvolvimento de IA.
Até agora, Jaeho Yoon, da Colorkrew Security, trouxe o melhor para você.
Muito obrigado.