Falha no Cursor permitia execução persistente por confiança indevida em configurações MCP

A CVE-2025-54136 afetava o modelo de aprovação do Cursor IDE e permitia trocar comandos em um MCP já autorizado sem novo aviso ao usuário, criando execução local silenciosa e persistente em projetos compartilhados.

Componente	Cursor IDE, processamento de configurações MCP em .cursor/rules/mcp.json e entradas mcpServers associadas a projetos.
Vetor	Um projeto compartilhado contém um MCP inicialmente benigno, o usuário aprova a execução uma vez e, depois, a mesma chave MCP é modificada para apontar command ou args para comandos maliciosos.
Impacto	Execução silenciosa de comandos locais no contexto do usuário, com possibilidade de shell reverso, acesso recorrente ao abrir o projeto e exposição de código-fonte, credenciais de nuvem e artefatos de desenvolvimento acessíveis ao usuário.
Prioridade	Atualizar o Cursor para uma versão corrigida, revisar MCPs já aprovados, auditar alterações em .cursor/ e investigar execuções de comandos iniciadas pelo IDE.
Artefatos	Arquivo .cursor/rules/mcp.json, objeto mcpServers, nomes de entradas MCP, campos command e args, histórico Git e eventos de criação de processo associados ao Cursor.
Mitigação	Após a correção, qualquer alteração em uma configuração MCP exige nova aprovação explícita antes de entrar em vigor.

Resumo técnico

A CVE-2025-54136 explorava uma falha no limite de confiança usado pelo Cursor IDE para configurações do Model Context Protocol. O IDE permite que projetos definam integrações MCP por meio de arquivos dentro de .cursor/, incluindo regras capazes de acionar fluxos com APIs remotas, saídas de modelos de linguagem e execução de comandos locais. O problema não estava na existência desse recurso, mas na forma como a aprovação era vinculada: depois que o usuário aceitava uma entrada MCP, o Cursor tratava futuras versões dessa entrada como confiáveis com base no nome da chave, mesmo quando os campos executáveis haviam sido alterados.

Na prática, um invasor com capacidade de influenciar o repositório de um projeto, uma ramificação compartilhada ou um fluxo de sincronização podia inserir primeiro um MCP aparentemente inofensivo em .cursor/rules/mcp.json, usando um comando benigno como demonstração de utilidade. Depois da aprovação inicial pelo usuário, a mesma entrada podia ser modificada para executar comandos arbitrários por meio de command e args. Quando o projeto era reaberto ou sincronizado, o Cursor reprocessava a configuração e executava o novo conteúdo sem exigir nova confirmação. Esse comportamento transformava um mecanismo de extensão de produtividade em um ponto de execução persistente no ambiente de desenvolvimento.

O impacto era especialmente sensível porque está classe de IDE opera perto de ativos críticos de engenharia. Um processo iniciado no contexto do usuário pode acessar repositórios locais, variáveis de ambiente, tokens presentes em arquivos de configuração, chaves usadas por ferramentas de nuvem, diretórios de build, caches de dependências e credenciais já disponíveis para a sessão. A falha não exigia exploração de memória, elevação direta ao núcleo do sistema operacional ou uma vulnerabilidade em um pacote de aplicação; a condição essencial era a quebra de confiança entre a aprovação inicial e a configuração executável efetivamente usada em execuções posteriores.

Fluxo técnico

O fluxo vulnerável começava quando o Cursor abria um projeto e varria o diretório .cursor/ em busca de configurações relacionadas a MCP. Um arquivo como .cursor/rules/mcp.json podia conter um objeto mcpServers, no qual cada entrada definia um nome lógico para o MCP, um command local e, opcionalmente, uma lista args. Quando uma entrada ainda não aprovada era encontrada, o IDE exibia um pedido de autorização. O desenho esperado seria considerar a identidade e o conteúdo executável da configuração no momento da decisão; a falha era tratar o nome da entrada como suficiente para manter a confiança em execuções futuras.

A exploração dependia de uma sequência simples. Primeiro, o invasor adicionava ao projeto um MCP com um nome estável e um comando benigno. O usuário abria o repositório no Cursor, via a solicitação de aprovação e aceitava a execução. Depois, o invasor alterava o mesmo registro MCP, preservando a chave já aprovada e substituindo os campos command ou args por uma instrução maliciosa. O conteúdo podia apontar para um interpretador local, para um comando do sistema ou para uma cadeia que estabelecesse acesso remoto, como um shell reverso. Como a confiança estava associada ao nome, a mudança do comportamento executável não disparava um novo prompt na versão vulnerável.

A consequência operacional era persistência condicionada ao ciclo normal de uso do projeto. Cada reabertura do workspace ou atualização do repositório podia levar o Cursor a reavaliar o MCP e acionar o comando modificado. Isso permitia execução recorrente sem nova ação do usuário, além da primeira aprovação. O ataque era particularmente adequado para ambientes colaborativos, nos quais alterações em arquivos versionados podem chegar por pull, merge, sincronização automática, revisão incompleta de ramificações ou reaproveitamento de templates internos. O invasor não precisava comprometer diretamente o binário do IDE; bastava introduzir ou modificar um arquivo de configuração que o próprio fluxo de desenvolvimento passava a interpretar como confiável.

Superfície afetada

A superfície principal incluía estáções de desenvolvimento que usavam Cursor com projetos contendo configurações MCP versionadas no diretório .cursor/. Ambientes de startup, times de pesquisa e equipes que adotam IDEs com automação baseada em modelo de linguagem ficavam mais expostos quando aceitavam configurações de projeto vindas de terceiros, forks, contribuições externas ou repositórios internos sem controle rígido sobre arquivos de automação. O risco aumentava quando o mesmo workspace tinha acesso a segredos operacionais, provedores de nuvem, infraestrutura de CI/CD, chaves SSH, tokens de Git, registros de pacotes ou código proprietário.

O vetor não se limitava a um sistema operacional específico no nível conceitual, porque o ponto vulnerável era a aprovação lógica de um comando MCP. O comando final, porém, dependeria do ambiente da vítima. O próprio contexto técnico demonstrava a possibilidade de troca para comandos arbitrários, incluindo cmd.exe em Windows e payloads capazes de abrir uma sessão reversa. O alcance do dano ficava limitado ao contexto do usuário que executava o Cursor, mas esse limite ainda é amplo em máquinas de desenvolvimento, nas quais permissões de usuário costumam bastar para acessar projetos, arquivos de credenciais, ferramentas de implantação e sessões autenticadas.

A versão corrigida mudou o comportamento de confiança: alterações em uma configuração MCP, mesmo pequenas mudanças de conteúdo, passam a exigir nova decisão explícita do usuário. Esse detalhe é importante para a avaliação defensiva, pois a presença de MCPs aprovados antes da atualização deve ser tratada como passivo a revisar. Um ambiente pode estar corrigido no binário atual, mas ainda conter histórico, commits, templates ou configurações antigas que merecem auditoria para excluir abuso anterior.

• Projetos com .cursor/rules/mcp.json versionado ou sincronizado entre usuários.
• Entradas mcpServers previamente aprovadas cujo command ou args mudou após a aprovação inicial.
• Estáções de trabalho com acesso local a repositórios privados, tokens de nuvem, chaves SSH, credenciais de registro de pacotes ou segredos de CI/CD.
• Fluxos colaborativos que permitem alterações em arquivos .cursor/ sem revisão de segurança específica.

Hunting e telemetria

A investigação deve começar pelo histórico do repositório e pelo endpoint. Em Git, procure adições e alterações em .cursor/rules/mcp.json, especialmente quando a chave MCP permanece igual e apenas command ou args mudam. Esse padrão é compatível com o abuso da confiança por nome: uma entrada inicialmente aceitável passa a executar outro binário ou outra cadeia de argumentos sem mudança visível no identificador lógico. Revisões devem comparar o conteúdo aprovado pelo usuário com versões posteriores do arquivo e identificar se a configuração foi alterada depois da primeira abertura do projeto no Cursor.

No endpoint, a telemetria mais útil envolve criação de processos e relacionamento pai-filho. Busque comandos iniciados pelo processo do Cursor ou por processos associados ao IDE, principalmente interpretadores de shell, utilitários de script, binários de rede e comandos que não fazem parte do fluxo normal daquele projeto. Como o material analisado não fornece hashes, domínios, endereços IP ou nomes específicos de payload, a detecção deve ser comportamental. Eventos de conexão de saída imediatamente após abertura do projeto, execução de comando a partir do diretório do workspace e repetição do mesmo processo a cada inicialização do IDE são sinais relevantes.

Também é necessário revisar artefatos de identidade e segredos. Caso haja indício de execução maliciosa, considere que variáveis de ambiente, arquivos de configuração de nuvem, tokens de Git, credenciais de gerenciadores de pacotes e chaves usadas por ferramentas de automação podem ter sido acessados pelo processo executado. A ausência de um IoC específico não reduz a gravidade; ela desloca a resposta para reconstrução temporal, correlação de processos, análise de rede e validação de mudanças no repositório.

• Diffs em .cursor/rules/mcp.json nos quais a mesma chave MCP mantém o nome, mas troca command ou args.
• Eventos de criação de processo em que o Cursor aparece como processo pai ou origem próxima de shells, interpretadores ou comandos incomuns.
• Conexões de saída iniciadas logo após abertura, reabertura ou sincronização de um projeto no Cursor.
• Execuções recorrentes ao abrir o mesmo workspace, sugerindo persistência ligada ao ciclo de inicialização do projeto.
• Acesso recente a arquivos de credenciais, diretórios de repositório, caches de dependências ou configurações de nuvem após a execução do MCP.

Mitigação

A primeira medida é atualizar o Cursor para uma versão em que alterações de MCP exijam nova aprovação. O comportamento corrigido invalida a premissa explorada pela CVE-2025-54136, porque a decisão do usuário passa a considerar mudanças posteriores na configuração. Depois da atualização, abra projetos sensíveis com atenção aos prompts de MCP e rejeite qualquer alteração inesperada. A correção do IDE deve ser combinada com revisão de repositórios, porque configurações maliciosas podem permanecer versionadas e voltar a aparecer em clones, forks ou ramificações antigas.

Em repositórios compartilhados, trate .cursor/ como superfície de execução, não como simples metadado de editor. Arquivos capazes de acionar comandos locais devem passar por revisão semelhante à aplicada a scripts de build, hooks, pipelines e manifests de dependência. Para organizações, controles de ramificação protection, CODEOWNERS, revisão obrigatória e alertas para alterações em .cursor/rules/mcp.json reduzem o risco de uma mudança discreta chegar a estáções de desenvolvimento. Quando MCPs forem necessários, documente a finalidade, o comando esperado e os argumentos permitidos, para que desvios sejam identificáveis durante revisão.

Se houver suspeita de exploração, contenha a máquina antes de apenas remover o arquivo. Preserve histórico Git, eventos de processo, logs de rede e cópias das configurações MCP para análise. Revogue credenciais que estavam acessíveis ao usuário afetado, incluindo tokens de Git, chaves de nuvem, credenciais de registros de pacotes e segredos usados por ferramentas locais. Refaça autenticações de serviços sensíveis e valide se houve alterações em pipelines, dependências, scripts de inicialização, hooks e arquivos de infraestrutura. A resposta deve considerar que o comando executado podia ter implantado persistência adicional fora do MCP original.

• Atualizar o Cursor para a versão corrigida antes de abrir projetos que contenham configurações MCP não revisadas.
• Auditar todos os arquivos .cursor/rules/mcp.json em repositórios internos, forks e templates usados por equipes de desenvolvimento.
• Criar regras de revisão para alterações nos campos mcpServers, command e args.
• Bloquear ou exigir aprovação adicional para comandos MCP que invoquem shells, interpretadores genéricos ou utilitários de rede sem justificativa técnica.
• Rotacionar credenciais acessíveis ao usuário caso logs indiquem execução não autorizada a partir do Cursor.