Em 29 de outubro de 2026, entre 17h27 e 04h35 do dia seguinte, no horário de Pequim, a extensão oficial do Claude Code no marketplace do Cursor foi substituída por uma versão maliciosa com um backdoor SSH. A janela de exposição durou cerca de 11 horas. As versões afetadas foram a 2.1.312 e a 2.1.313, para macOS arm64 e Windows x64. Segundo o Cursor, até cerca de 5.000 usuários podem ter baixado a extensão ou recebido a atualização automática.
Não foi um plugin falsificado que entrou no marketplace. O pacote instalado pelos usuários tinha o nome oficial Anthropic.claude-code, e a interface e as funções pareciam as mesmas de sempre. Por isso, muita gente nem percebeu que o instalou. É também por isso que apenas desinstalar a extensão ou atualizar a versão não basta. O código malicioso já havia inserido uma chave pública SSH, configurado um script de persistência para iniciar com o sistema e enviado informações da máquina ao atacante. Para concluir a limpeza, é preciso fazer três coisas: remover a chave, eliminar a persistência e trocar as credenciais.
O que você vai encontrar aqui: este artigo divide o processo em 5 etapas, seguindo a ordem «o que você vai ver → o que fazer → como saber se deu certo». Mesmo sem ser especialista em segurança, você consegue verificar e limpar o sistema em cerca de meia hora, incluindo a troca da chave API da APIYI.
Legenda: a janela maliciosa durou cerca de 11 horas, e a 2.1.314 foi a primeira versão limpa após o incidente.
Antes de entrar em pânico: o que aconteceu com a extensão Claude Code
Vamos começar pelos fatos. Todas as informações da tabela abaixo vêm do comunicado de segurança da Cursor e de respostas públicas de funcionários da Anthropic.
| Item | Fato |
|---|---|
| Incidente | A extensão Anthropic.claude-code no marketplace da Cursor foi adulterada para incluir uma backdoor SSH persistente |
| Versões afetadas | 2.1.312 e 2.1.313 (a Cursor acrescentou a 2.1.312 na atualização do comunicado em 30 de outubro) |
| Plataformas | macOS (darwin-arm64) e Windows (win32-x64); o código também contém uma ramificação para Linux |
| Janela de exposição | 29/10, das 02h27 às 13h35 no horário do Pacífico; ou das 17h27 de 29/10 às 04h35 de 30/10 no horário de Pequim |
| Alcance | Segundo a Cursor, até 5.000 usuários; essa é uma estimativa de exposição, não o número de infecções confirmadas |
| Situação atual | As versões maliciosas foram removidas; o marketplace voltou a funcionar após ser desativado, reconstruído e auditado; segundo a Cursor, o provedor de hospedagem tirou o servidor do atacante do ar |
| Versão limpa | A 2.1.314 foi a primeira versão limpa; em 31 de outubro, a mais recente era a 2.1.316 |
Legenda: captura do comunicado de segurança da Cursor (a ser adicionada durante a edição).
Algumas informações que circularam logo após o incidente estavam erradas. Vale corrigir três pontos:
- A versão 2.1.312 também está na lista de afetadas. A Cursor anunciou inicialmente apenas a 2.1.313 e acrescentou a 2.1.312 depois. Se você instalou a 2.1.312 pelo marketplace da Cursor durante a janela de exposição, também precisa verificar sua máquina.
- A adulteração ocorreu apenas no Cursor Marketplace. As primeiras notícias diziam que Open VSX, o marketplace da Microsoft e npm também tinham sido afetados, mas essas informações foram corrigidas. A Socket auditou os registros de alterações dos repositórios e não encontrou nenhum registro de publicação ou remoção da versão 2.1.313.
- A versão 2.1.313 nunca foi publicada nos canais oficiais da Anthropic. Segundo David Dworken, engenheiro de segurança da Anthropic, essa versão nunca apareceu no Open VSX, no marketplace oficial do VS Code ou em qualquer servidor oficial da Anthropic. Para evitar confusão com a numeração, a versão oficial seguinte pulou diretamente para a 2.1.314.
Ainda não se sabe quem fez isso nem como obteve permissão para publicar a extensão. Felix Rieseberg, da Anthropic, afirmou que os sistemas da empresa e os computadores de seus funcionários não foram invadidos: alguém usou permissões de acesso ao marketplace da Cursor para publicar a versão adulterada. O comunicado da Cursor, por sua vez, não explica como o atacante obteve essa permissão. A Cursor havia aberto o Marketplace para envios públicos em outubro, mas não há esclarecimento oficial sobre uma possível relação com o ataque. Por isso, não vamos especular. Para quem desenvolve, é melhor verificar a própria máquina do que tentar adivinhar a causa.
Por que até a extensão oficial do Claude Code foi comprometida
A primeira reação de muita gente é: como um pacote oficial pode conter código malicioso? Para entender, é preciso saber como as extensões de IDE funcionam. Elas são executadas com as permissões da IDE e podem ler e alterar seu código, variáveis de ambiente e arquivos no diretório do usuário. Além disso, executam código assim que são carregadas: você não precisa abrir uma janela de diálogo nem usá-las ativamente.
A análise da Phorion mostrou que o código malicioso era uma função de execução imediata (IIFE) de 66 linhas, inserida no início do arquivo extension.js, antes do código normal da extensão. Assim que o módulo é carregado pelo Node, essa função é executada, antes mesmo do callback activate. O arquivo extension.js adulterado tinha 3.692.922 bytes, cerca de 7 KB a mais que a versão limpa anterior. Como o ataque não dependia do hook postinstall do npm, não se tratava de um pacote npm envenenado: o código foi alterado diretamente no pacote de instalação VSIX.
Uma analogia ajuda a entender: não é como se alguém tivesse colocado um remédio falsificado na farmácia. É como se uma caixa de uma marca legítima na prateleira oficial tivesse sido substituída por uma versão adulterada. O nome, a embalagem e o código de barras são verdadeiros; só o conteúdo está errado. Por isso, nesse caso, a orientação de sempre conferir se o publicador é oficial não foi suficiente.
Legenda: a cadeia do backdoor tem seis etapas; desinstalar a extensão só interrompe a primeira.
Há três equívocos comuns sobre esse incidente:
- «Nome oficial do pacote significa build oficial»: o nome do pacote e a identidade do publicador eram oficiais, mas a build não foi feita pela Anthropic. No Open VSX também existe uma versão 2.1.312, limpa e publicada em 27 de outubro. Mesmo número de versão, origens diferentes e níveis de segurança diferentes.
- «Só a versão 2.1.313 foi afetada»: a versão 2.1.312 no marketplace do Cursor também era maliciosa.
- «Basta desinstalar ou atualizar»: segundo o comunicado do Cursor, apenas desinstalar a extensão pode não ser suficiente, pois o payload deixa scripts de persistência que continuam rodando de forma independente.
5 passos para detectar e remover o backdoor na extensão Claude Code
Siga os 5 passos em ordem. Os três primeiros são de verificação, o quarto é de limpeza e o quinto encerra o processo. Cada passo explica o que fazer e como confirmar que foi concluído.
Legenda: fluxo em 5 passos. Não deixe de substituir as credenciais no quinto passo.
① Verifique a versão e a origem da extensão. Abra o painel de extensões do Cursor, procure Claude Code e confira o número da versão e o publicador. Depois, no terminal, examine o diretório ~/.cursor/extensions/ (no Windows, %USERPROFILE%\.cursor\extensions\) e veja se há pastas com anthropic.claude-code-2.1.312 ou 2.1.313 no nome. Mesmo que você já use uma versão mais recente, pastas antigas deixadas para trás indicam que você pode ter instalado uma versão afetada durante o período de risco.
② Verifique a chave pública svc-telemetry. No macOS e no Linux, execute grep -n svc-telemetry ~/.ssh/authorized_keys. No Windows, verifique os dois arquivos: %USERPROFILE%\.ssh\authorized_keys e C:\ProgramData\ssh\administrators_authorized_keys. O código malicioso verifica se a string svc-telemetry está presente no arquivo, então olhar apenas os comentários não é suficiente. Também recomendamos executar ssh-keygen -lf ~/.ssh/authorized_keys para listar as impressões digitais de todas as chaves públicas e compará-las, uma a uma, com a impressão digital do atacante: SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk.
③ Verifique os mecanismos de persistência e os processos de túnel. Os locais a verificar variam conforme o sistema:
- macOS:
~/Library/LaunchAgents/com.apple.sysmond.plist,~/.config/.smt,~/.config/.smtke arquivos.stk_*no diretório temporário. O nome desse LaunchAgent se disfarça de componente do sistema da Apple, mas na verdade é um item de inicialização no nível do usuário. - Windows: execute
schtasks /query /tn SysMonpara procurar a tarefa agendada; verifiquesysmon.cmdna pasta de inicialização, além de%USERPROFILE%\.config\smt.cmde%TEMP%\.stk_*. - Linux: execute
crontab -le procure entradas com@rebootque apontem para~/.config/.smt. - Todas as plataformas: verifique se há processos
sshouautosshcom-R '*:0:localhost:22'nos parâmetros.
| Passo | O que fazer | Critério de conclusão |
|---|---|---|
| ① Origem da extensão | Verificar o painel de extensões e ~/.cursor/extensions/ |
Não há diretórios 2.1.312 / 2.1.313, e a versão atual é ≥ 2.1.314 |
| ② Chave pública | Procurar svc-telemetry e comparar as impressões digitais |
Não há correspondências nos dois tipos de arquivo authorized_keys |
| ③ Persistência | Verificar plist / SysMon / cron / processos de túnel | Os arquivos não existem e não há processos ssh com o parâmetro -R |
| ④ Remoção | Executar o script oficial do Cursor e atualizar | O script termina com código 0 e, ao verificar novamente ①②③, não há vestígios |
| ⑤ Credenciais | Substituir credenciais Git, CI, nuvem, SSH e chaves API | As credenciais antigas foram desativadas e os logs de chamadas não mostram anomalias |
④ Se houver comprometimento, execute o script oficial de limpeza. Se qualquer uma das verificações em ② ou ③ indicar comprometimento, siga as instruções do comunicado da Cursor. No macOS, baixe cursor.com/static/security/claude-code-extension/remediate-macos.sh e execute bash remediate-macos.sh como o usuário afetado (não use root). No Windows, baixe remediate-windows.ps1, abra o PowerShell com a opção «Executar como administrador» e execute powershell -ExecutionPolicy Bypass -File .\remediate-windows.ps1. Baixe os scripts apenas do site oficial da Cursor e não use ferramentas de «limpeza em um clique» de origem desconhecida. O script remove a extensão maliciosa, os mecanismos de persistência, os processos de túnel e a chave pública do invasor; se ainda houver resíduos, ele encerrará com um código diferente de 0. Após a limpeza, atualize a extensão para uma versão superior à 2.1.314. Até 31 de outubro, é possível instalar diretamente a 2.1.316.
⑤ Faça a rotação das credenciais. Isso inclui tokens do GitHub / GitLab, tokens de CI/CD, Access Keys de provedores de nuvem, chaves privadas SSH, tokens do npm / PyPI e a chave API da APIYI apiyi.com configurada nessa máquina. Faça a rotação em uma máquina confiável. Se os logs de SSH mostrarem que o túnel realmente foi usado, a Phorion recomenda reconstruir o host, pois isso é mais seguro do que limpar cada item separadamente.
Por que você ainda precisa verificar o backdoor do Claude Code, mesmo que a maioria das máquinas não tenha sido acessada
Primeiro, a notícia relativamente boa: segundo a análise da Phorion, um bug no próprio código malicioso impediu que o serviço SSH fosse ativado na maioria das máquinas.
No macOS, o script executava systemsetup -getremotelogin com permissões de usuário comum e recebia uma mensagem informando que eram necessárias permissões de administrador. Mesmo assim, o código de saída era 0. O script verificava apenas se a saída continha Off. Como a mensagem não continha essa palavra, ele concluía erroneamente que o login remoto já estava ativado e pulava a etapa de ativação do SSH. No Windows, o comando PowerShell para instalar o OpenSSH Server era passado a uma função auxiliar que tinha /bin/sh definido diretamente no código. Como o Windows padrão não tem /bin/sh, essa etapa provavelmente falhava. A Cursor também afirmou que, a menos que o Cursor fosse iniciado com permissões de administrador — algo raro —, a ativação do serviço SSH e a criação do túnel falhariam.
Mas isso não significa que está tudo bem. A chave pública, o script de persistência e o beacon de reconhecimento já foram instalados. Fazendo uma analogia: a ferramenta dos criminosos para abrir a fechadura estava com defeito, então muitas portas não foram abertas. Mas a chave já está na fechadura, e uma nova tentativa é feita a cada 60 segundos.
| Categoria | Indicador (IOC, com defang aplicado) | Descrição |
|---|---|---|
| Rede | 134[.]209[.]82[.]225:22, nome de usuário tunnel |
Destino do túnel SSH reverso |
| Rede | 134[.]209[.]82[.]225:8099/beacon |
Beacon HTTP sem criptografia que envia informações da máquina |
| Chave pública | Comentário svc-telemetry |
Adicionada a authorized_keys |
| Impressão digital | SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk |
Impressão digital da chave pública do atacante |
| Chave privada do túnel | SHA256:KOAU57+ZG6u3MG4WwzPzPX2O5YEe9qdOC1Bl+6MVyDQ |
Arquivo .stk_* gravado no diretório temporário |
| Arquivo | SHA-256 de extension.js começa com ecb58cb2 |
Arquivo principal da extensão maliciosa; valor completo no comunicado da Cursor |
Legenda: captura de tela da tabela de hashes dos arquivos VSIX maliciosos (a ser adicionada na edição).
Preste atenção especial às seguintes situações:
- O login remoto já estava ativado. Se o login remoto estava ativado no Mac em “Ajustes do Sistema → Geral → Compartilhamento”, ou se
Get-Service sshdmostra que o serviço está em execução no Windows, o backdoor tem condições de funcionar. - Servidor fora do ar não significa máquina limpa. O servidor do atacante está indisponível no momento, mas o script de persistência continua tentando se conectar. Sem uma limpeza, a máquina continua em estado inseguro.
- Verifique os logs de acesso SSH. No macOS, execute
log show --predicate 'process == "sshd"' --last 7d. No Linux, consulte/var/log/auth.log. No Windows, verifique os logs OpenSSH/Operational no Visualizador de Eventos. Procure principalmente registros de autenticação bem-sucedida vindos de127.0.0.1ou::1com a chave pública svc-telemetry. Se encontrar um único registro, trate a máquina como acessada pelo atacante e considere reconstruí-la.
O código malicioso também coletou nome da máquina, nome de usuário, informações do sistema, diretório de trabalho, e-mail global do Git, IP público e os nomes de até 40 variáveis de ambiente. A conclusão da Phorion é clara: o bug reduziu a probabilidade de acesso, mas não deve ser considerado uma linha de defesa.
Depois da invasão da extensão Claude Code, é preciso trocar a chave APIYI?
Sim. O código malicioso coletava os nomes de variáveis de ambiente que continham KEY, TOKEN, SECRET, PASS, AWS ou GCP. Embora não lesse diretamente os valores, o atacante já sabia quais credenciais existiam na sua máquina. Se o túnel estivesse disponível, ele poderia ler de forma interativa os valores dessas variáveis, arquivos de configuração e o histórico do shell. Portanto, se a máquina teve a versão 2.1.312 ou 2.1.313 instalada durante o período afetado, trate a chave APIYI apiyi.com configurada nela como possivelmente exposta.
Um ponto importante: a APIYI não foi invadida. O risco indireto é de que a chave na sua máquina tenha sido lida. Por isso, basta fazer a rotação da chave, sem entrar em pânico. Veja como:
| Etapa | Ação | Verificação |
|---|---|---|
| 1 | Abra a página de tokens no console: api.apiyi.com/token |
Confira se a lista de chaves existentes aparece |
| 2 | Clique em “Adicionar” no canto superior direito e selecione o grupo ClaudeCode para a chave usada pelo Claude Code |
Uma nova chave começando com sk- é gerada |
| 3 | Troque o valor de ANTHROPIC_AUTH_TOKEN pela nova chave e mantenha ANTHROPIC_BASE_URL como https://api.apiyi.com |
Atualize também o env em ~/.claude/settings.json |
| 4 | Feche e abra o terminal e reinicie o Claude Code | Confira se é possível conversar e fazer chamadas normalmente |
| 5 | Volte à página de tokens e desative ou exclua a chave antiga | A chave antiga fica desativada |
| 6 | Confira os logs de chamadas | Não há consumo de modelos inesperados ou em horários incomuns |
Se seus scripts usam a interface compatível com OpenAI, lembre-se de trocar também a chave associada a base_url="https://api.apiyi.com/v1" no código. Depois, envie uma requisição de teste com a nova chave para confirmar que funciona. Se a chave antiga ainda for usada em outras máquinas ou projetos, substitua-a em cada um deles, não apenas em uma máquina.
🎯 Boa prática: a página de tokens da APIYI apiyi.com permite definir um limite de saldo e uma data de validade para cada chave. Vale adotar “uma chave por máquina” e separar desenvolvimento de produção. Assim, se algo parecido acontecer novamente, você só precisará desativar a chave correspondente.
Por fim, vale reforçar: não são apenas as chaves da APIYI que precisam ser substituídas. Tokens do GitHub / GitLab, chaves de CI, Access Keys de provedores de nuvem, chaves privadas SSH e tokens npm / PyPI também devem passar por rotação. Faça isso em uma máquina confiável.
Perguntas frequentes sobre o comprometimento da extensão Claude Code
Q1: Uso apenas a loja oficial do VS Code. Posso ser afetado?
Até o momento, não há evidências de que sim. A única fonte de distribuição verificável foi o Cursor Marketplace; a versão maliciosa 2.1.313 não apareceu nem na loja da Microsoft nem no Open VSX.
Q2: Uso apenas o Claude Code CLI, sem extensão de IDE. Posso ser afetado?
Não por este incidente. O pacote CLI no npm não foi comprometido; apenas o VSIX da extensão na loja do Cursor foi afetado.
Q3: Uso o Cursor, mas não instalei a extensão Claude Code. Posso ser afetado?
Não. O código malicioso só é executado quando essa extensão é carregada. Se tiver dúvidas, pesquise por `svc-telemetry` conforme a etapa ②. A verificação leva apenas alguns segundos.
Q4: Atualizar para a versão 2.1.314 resolve o problema?
A atualização apenas impede que você seja afetado novamente. A chave pública e o script de persistência já gravados, assim como as informações vazadas, não desaparecem com a atualização. Ainda é necessário seguir as etapas ②③④⑤.
Q5: Devo instalar a versão 2.1.316 agora?
Sim. Em 31 de outubro, a versão 2.1.316 era a mais recente no GitHub Releases. Tanto a 2.1.314 quanto a 2.1.316 são versões limpas. Não houve uma versão 2.1.315 entre elas, e isso é normal.
Q6: Preciso reinstalar o sistema?
Se apenas a chave pública ou o mecanismo de persistência forem encontrados, executar o script oficial e concluir a verificação geralmente é suficiente. Se os logs de SSH mostrarem que o túnel foi realmente usado, a Phorion recomenda recriar o host, pois não é possível deduzir pela amostra o que o invasor fez depois de acessar o sistema.
Q7: As 5.000 pessoas são casos confirmados?
Não. O Cursor informou que foram “até 5.000 usuários”: essa é uma estimativa de exposição por downloads e atualizações automáticas, não o número de infecções confirmadas. O Cursor disse que entrará em contato diretamente com os usuários afetados.
Q8: Meu computador pode ser controlado remotamente?
Por causa do bug mencionado anteriormente, o serviço SSH não foi ativado na maioria dos hosts macOS e Windows, e o servidor dos invasores também está fora do ar. Mas, se o acesso remoto já estava ativado no seu computador, o risco é real. Consulte os logs de SSH para verificar se houve acesso.
Q9: Minha chave APIYI pode vazar?
A plataforma APIYI em si não foi invadida. O risco é que as variáveis de ambiente do seu computador possam ter sido lidas. Por isso, recomendamos criar uma nova chave em api.apiyi.com/token, atualizar a configuração e desativar a chave antiga.
Principais pontos sobre o comprometimento da extensão Claude Code
- Versões afetadas: 2.1.312 e 2.1.313 no marketplace do Cursor. Outros canais oficiais não foram afetados.
- Execução ao carregar: não é preciso usar a extensão; basta carregá-la para que o backdoor seja instalado.
- Três vestígios: a chave pública em
authorized_keys, o script de persistência e as informações enviadas pelo beacon. - A maioria não sofreu acesso indevido: o código malicioso tinha um bug, mas isso não é motivo para deixar de investigar.
- Como remover: execute o script oficial, atualize para a versão 2.1.314 ou superior e, se necessário, reconstrua o host.
- Credenciais: faça a rotação das credenciais de Git, CI, nuvem e SSH, além da chave API da APIYI.
Referências
- Comunicado de segurança do Cursor: versões afetadas, IOCs e script de remoção
- Link:
cursor.com/blog/claude-code-extension-security-notice - Análise técnica da Phorion: análise do código malicioso e do bug
- Link:
phorion.io/blog/offical-claude-code-vsx-compromise - Análise da StepSecurity: verificação do registro e das versões
- Link:
stepsecurity.io/blog/claude-code-extension-trojanized - Releases do Claude Code no GitHub: histórico oficial de versões
- Link:
github.com/anthropics/claude-code/releases
Resumo
O que torna esse incidente diferente é que a versão maliciosa usava o nome do pacote oficial. Por isso, conferir se o publicador é oficial não basta. A ordem recomendada é: primeiro, verifique a versão e a origem da extensão; depois, procure chaves públicas e mecanismos de persistência; se encontrar indícios, execute o script oficial; por fim, faça a rotação de todas as credenciais em uma máquina confiável. Usuários da APIYI podem aproveitar para reorganizar os grupos, limites e prazos de validade das chaves seguindo a regra de «uma chave por máquina». Para mais detalhes sobre a configuração, consulte a documentação de gerenciamento de tokens da APIYI em apiyi.com.
Autor: Equipe técnica da APIYI
Troca de informações técnicas: entre em contato conosco pela página inicial do site oficial da APIYI. Para configurar a integração com o Claude Code, consulte a central de documentação em docs.apiyi.com
Desta vez, não basta trocar de versão: é preciso cuidar das chaves, da persistência e das credenciais para encerrar o incidente.
