Em 29 de outubro de 2026, um evento raro e alarmante sacudiu a comunidade de desenvolvedores: uma versão maliciosa da extensão oficial do Claude Code, publicada no marketplace de extensões da Cursor (a empresa por trás do editor de código mais popular do momento), esteve disponível para instalação por aproximadamente onze horas, infectando até 5.000 usuários. O ataque não explorou uma vulnerabilidade no código do Claude Code — a extensão original foi simplesmente substituída por uma versão trojanizada que, ao ser instalada, plantava uma chave SSH controlada pelo atacante no arquivo authorized_keys, tentava habilitar o serviço SSH local e abria um túnel reverso para um servidor remoto.
O que torna esse incidente particularmente significativo vai além da sofisticabilidade técnica do ataque. Ele ilustra uma transformação estrutural na ameaça cibernética: desenvolvedores que usam ferramentas de IA para codificação estão se tornando alvos diretos de ataques de cadeia de suprimentos, e um único plugin malicioso pode entregar acesso root ao ambiente de desenvolvimento inteiro. A extensão maliciosa, nas versões 2.1.312 e 2.1.313, rodava código malicioso antes mesmo do callback de ativação da extensão ser chamado — o código injetado se inseria no carregamento do módulo extension.js, executando automaticamente sempre que o IDE ou o Cursor iniciavam.
O ataque em detalhes
A extensão trojanizada continha um loader de 66 linhas que era prependado ao bundle original da extensão. Quando a extensão era carregada, o loader executava imediatamente, sem nenhuma interação do usuário, e executava uma cadeia de ações em quatro estágios.
O primeiro estágio preparava o acesso SSH. O malware assegurava que o diretório ~/.ssh existisse e acrescentava uma chave pública Ed25519 com o comentário `svc-telemetry` ao arquivo authorized_keys do usuário. Simultaneamente, tentava habilitar o serviço SSH local — no macOS, através do comando `systemsetup -setremotelogin on`; no Linux, via systemctl; no Windows, ativando o servidor SSH do OpenSSH. Em seguida, iniciava um túnel SSH reverso contínuo para o IP 134.209.82.225 na porta 8099, usando um loop de retry a cada 60 segundos com `autossh`, caindo para `ssh` se o autossh falhasse. A conexão usava `-N -R '*:0:localhost:22'` com verificação de host desabilitada (`StrictHostKeyChecking=no`).
O segundo estágio era a persistência. O malware instalava mecanismos de boot em cada plataforma: no macOS, um LaunchAgent malicioso chamado `com.apple.sysmond.plist` — nomeado propositalmente para se passar por um serviço legítimo da Apple — armazenado em ~/Library/LaunchAgents/; no Linux, uma entrada de crontab do usuário `@reboot` executando ~/.config/.smt; no Windows, uma tarefa agendada chamada SysMon acessível via `schtasks`, com um fallback para um script no Startup folder. O loader também escrevia uma chave privada em PEM num arquivo oculto ~/.config/.smtk e, num arquivo temporário correspondendo ao padrão $TMPDIR/.stk_*, criando as credenciais que sustentavam tanto o túnel quanto a chave SSH plantada.
O terceiro estágio era o beacon. O malware enviava dados do host para o servidor atacante via HTTP puro (sem TLS) no path /beacon — uma decisão interessante que facilita a detecção no fluxo de rede. Os dados incluíam hostname, username, sistema operacional, arquitetura, caminho do diretório home, diretório de trabalho atual, e-mail configurado no Git, endereço IP público e, notavelmente, os nomes de variáveis de ambiente que correspondiam a padrões como KEY, TOKEN, SECRET, PASS, AWS ou GCP. O beacon enviava até 40 nomes de variáveis por POST, mas não os valores — o que não significa que os valores estejam a salvo, mas sim que o atacante estava primeiro mapeando quais credenciais estavam disponíveis no ambiente antes de tentar acessá-las via backdoor.
O quarto estágio era a exfiltração de contexto adicional. O malware coletava nomes de diretórios de trabalho, permitindo que o operador entendesse quais repositórios o desenvolvedor estava manipulando — informação valiosa para direcionar ataques adicionais contra infraestrutura de CI/CD ou repositórios de código.
Por que o ataque foi mais inofensivo do que poderia ter sido
Um ponto crucial: erros de codificação no malware impediram que ele funcionasse como pretendido na maioria das plataformas. No macOS, o comando `systemsetup -getremotelogin` retorna o código 0 com uma mensagem de erro quando o Remote Login está desabilitado — o malware interpretou esse código como sucesso e parou de tentar habilitar o SSH. Isso significa que, na maioria dos Macs, o túnel reverso nunca foi estabelecido porque o serviço SSH local não estava rodando e o malware não conseguiu ativá-lo.
Mesmo em sistemas onde o túnel foi estabelecido, a conexão requeria que o servidor remoto aceitasse a conexão entrante e que as configurações de servidor permitissem login via chave SSH — o que é incomum em ambientes corporativos. Em outras palavras, o malware plantou a chave SSH e instalou persistência, mas raramente conseguiu efetivamente abrir uma porta de entrada interativa.
Os pesquisadores da Daylight Security, que monitoraram casos reais de infecção em desenvolvedores, confirmaram que pelo menos dois casos reais foram identificados: em ambos, EDR tools dispararam alertas (CrowdStrike registrou eventos PemFileWritten quando chaves privadas foram escritas em ~/.config/.smtk, e o processo do IDE rodou comandos de SSH com `-R '*:0:localhost:22'`). No entanto, a extensão Claude Code original não tinha nenhuma das permissões que o malware precisava — e o ataque depurou inteiramente de vulnerabilidades de trust entre o IDE e suas extensões, não de uma falha no software em si.
O papel da Cursor e a resposta
A Cursor foi rápida em agir. Assim que o marketplace detectou a extensão maliciosa, ela foi removida, o marketplace foi desligado completamente por cautela, as chaves foram rotacionadas e o marketplace foi reconstruído antes de voltar ao ar. A Cursor confirmou que nenhum outro extension foi comprometido e trabalhou com o provedor de hospedagem para derrubar o servidor do atacante.
A empresa também emitiu um guia de segurança hardening, recomendando que organizações restrinjam extensões a editores aprovados e configurem um cooldown de instalação — atrasando a instalação de novas versões de extensões por um período configurável. Essas medidas, no entanto, protegem apenas organizações corporativas que adotam explicitamente essas configurações. Desenvolvedores individuais que atualizam extensões automaticamente continuam vulneráveis.
A Cursor estima que até 5.000 usuários foram afetados. A empresa publicou scripts de remediação específicos para cada plataforma, incluindo instruções para remover o LaunchAgent malicioso, a entrada de crontab, a tarefa agendada no Windows, e a chave SSH plantada. O ponto crucial que a Cursor enfatizou: desinstalar a extensão não remove os artefatos maliciosos — o atacante projetou o malware para sobreviver à remoção da extensão, escrevendo artefatos fora do diretório de instalação.
O que isso significa para o futuro da segurança de desenvolvedores
Esse incidente marca um momento de inflexão. Historicamente, ataques de cadeia de fornecimento visavam bibliotecas npm, pacotes PyPI, repositórios Git ou ferramentas de CI/CD — alvos que exigiam que o atacante comprometesse pacotes amplamente distribuídos. A extensão Claude Code, no entanto, era um alvo muito mais específico: uma extensão de IDE usada por desenvolvedores que já estavam configurados com permissões elevadas em seus próprios computadores.
Desenvolvedores carregam credenciais de alto valor em suas máquinas pessoais: chaves SSH, credenciais AWS e GCP, tokens de API, sessões autenticadas de CI/CD. Uma extensão maliciosa de IDE tem acesso direto a tudo isso — não apenas porque roda no contexto do usuário, mas porque pode ler arquivos que outras ferramentas maliciosas jamais alcançariam. O malware da extensão Claude Code não precisou de um exploit — ele simplesmente rodou como o IDE, com as mesmas permissões.
A extensão Claude Code é um caso emblemático, mas o padrão é mais amplo. À medida que desenvolvedores adotam ferramentas de IA para codificação — Claude Code, GitHub Copilot, Cursor, Windsurf —, cada uma dessas ferramentas oferece extensões que rodam com as permissões do IDE e do usuário. Um único plugin malicioso pode entregar acesso root ao ambiente de desenvolvimento inteiro.
O que diferencia esse ataque de outros é o nível de planejamento. O malware foi desenhado para persistir mesmo após a desinstalação da extensão — o que indica que o atacante não estava buscando uma instalação rápida de baixa complexidade, mas sim acesso interativo persistente e de longo prazo. O beacon que enviava nomes de variáveis de ambiente ao servidor atacante sugere que a intenção era usar essas variáveis como contexto para ataques adicionais, talvez para rotular contas cloud ou acessar repositórios.
O vetor de comprometimento — o marketplace de extensões da Cursor — também é interessante. A Cursor não usa o Visual Studio Marketplace nem o npm para distribuição; seu próprio marketplace é o canal de distribuição. Isso significa que o atacante não precisou comprometer o sistema de distribuição oficial da Anthropic (que, segundo a empresa, não foi afetado), mas sim explorar o pipeline de publicação do marketplace da Cursor. Um atacante que comprometeu ou burlou o sistema de revisão de extensões da Cursor — ou um membro da equipe com acesso privilegiado — foi capaz de publicar uma versão trojanizada da extensão oficial.
A pergunta que fica: em um mundo onde as ferramentas de desenvolvimento mais populares são cada vez mais alimentadas por IA e estendidas por plugins de terceiros, quem é responsável por garantir a integridade dessas ferramentas? A resposta curta é: o desenvolvedor individual. A resposta honesta é: ninguém, verdadeiramente. Até que a indústria resolva esse problema de forma coletiva, cada desenvolvedor que instala extensões em seu IDE está, efetivamente, fazendo um salto de fé.
Fontes: Cursor, Microsoft Security Research, Netskope Threat Labs
✓ Fontes independentes cruzadas e verificadas antes da publicação
