Backdoor no Cursor: Como uma extensão falsa do Claude Code expôs até 5.000 desenvolvedores

No dia 29 de outubro de 2026, o ecossistema de desenvolvimento de software foi alvo de um ataque de cadeia de suprimentos (supply-chain attack) cirúrgico. Uma versão adulterada da extensão oficial anthropic.claude-code foi disponibilizada no Cursor Extension Marketplace, uma loja de plugins voltada para o editor de código Cursor. Durante um intervalo de aproximadamente 11 horas, o pacote malicioso operou silenciosamente, injetando um loader em JavaScript programado para estabelecer um backdoor via Secure Shell (SSH) persistente nas máquinas das vítimas, além de coletar metadados sensíveis do ambiente de desenvolvimento.

Este incidente evidencia a vulnerabilidade crescente das ferramentas assistidas por Inteligência Artificial e dos marketplaces de nicho, que têm se tornado alvos primários para agentes de ameaça em busca de acesso corporativo. A Anthropic, criadora do modelo Claude, confirmou que seus sistemas internos não foram comprometidos e que a extensão maliciosa não foi desenvolvida ou assinada por eles. O ataque ficou estritamente confinado ao marketplace do Cursor, não afetando os pacotes distribuídos na Microsoft Visual Studio Marketplace ou o pacote oficial @antropic-ai/claude-code via npm.

Contexto e antecedentes da invasão

A adoção de editores de código orientados por IA, como o Cursor, cresceu exponencialmente nos últimos anos. Desenvolvedores utilizam extensões para integrar assistentes de IA diretamente em seus fluxos de trabalho, permitindo a geração, refatoração e análise de código em tempo real. A extensão Claude Code é uma das ferramentas mais procuradas neste segmento, o que a torna um alvo ideal para campanhas de injeção de código ou typosquatting.

Historicamente, ataques de supply-chain em marketplaces de extensões exploram a confiança implícita que os usuários depositam nessas plataformas. Antes deste incidente, desenvolvedores instalavam e atualizavam a extensão Claude Code via Cursor Marketplace sem incidentes. No entanto, o controle de qualidade e as políticas de verificação automatizada em marketplaces menores ou específicos costumam ser menos rigorosos em comparação com ecossistemas estabelecidos, como o da Microsoft.

Em 29 de outubro de 2026, às 02:27 AM (PDT), o cenário mudou. A infraestrutura do marketplace do Cursor passou a distribuir versões comprometidas da extensão, permitindo que o código de terceiros fosse executado com os mesmos privilégios do usuário no sistema operacional. A janela de exposição permaneceu aberta até as 13:35 PM (PDT), momento em que a anomalia foi detectada, a extensão removida e a plataforma reiniciada.

A anatomia do ataque e os dados concretos

A análise técnica conduzida por equipes de inteligência em ameaças revelou a mecânica do ataque. As versões maliciosas distribuídas foram especificamente a 2.1.312 e a 2.1.313 da extensão anthropic.claude-code. Durante o período de atividade, o Cursor estima que até 5.000 usuários de sistemas Windows e macOS tenham baixado ou atualizado automaticamente para as versões comprometidas.

O ataque não dependia de binários externos; ele utilizava um loader de 66 linhas em JavaScript inserido no pacote, executado imediatamente antes da inicialização legítima da extensão. O fluxo de infecção ocorria em cinco etapas rigorosas:

1. Reconhecimento (Reconnaissance): O loader coletava informações fundamentais do host, incluindo nome da máquina, nome do usuário, sistema operacional, arquitetura, diretório de trabalho, caminho da pasta home e o e-mail global configurado no Git. Mais criticamente, ele varria as variáveis de ambiente em busca de chaves que contivessem termos como SECRET, TOKEN, PASS, AWS ou GCP, armazenando os nomes de até 40 variáveis compatíveis.
2. Preparação de Acesso SSH: O script verificava o arquivo authorized_keys do usuário. Se não encontrasse o marcador identificador svc-telemetry, ele injetava uma chave pública Ed25519 embutida no código. Isso autorizava o acesso de qualquer indivíduo em posse da chave privada correspondente.
3. Estabelecimento do Túnel Reverso: O código decodificava uma segunda chave privada, gravando-a em um arquivo temporário oculto chamado .stk_ (seguido por dez caracteres hexadecimais). Em seguida, utilizava binários nativos do sistema (ssh ou autossh no macOS/Linux, e um loop de PowerShell no Windows) para iniciar um túnel SSH reverso. O comando executado incluía os argumentos -N -R *:0:localhost:22, solicitando que o servidor remoto (controlado pelo atacante) redirecionasse conexões para a porta 22 (SSH local) da máquina da vítima. O IP utilizado pela infraestrutura do atacante foi identificado como 134.209.82.225:8099.
4. Persistência no Sistema Operacional: O loader gravava scripts e configurações de inicialização específicos para cada plataforma, garantindo que o túnel reverso e o acesso SSH sobrevivessem à reinicialização da máquina ou ao fechamento do editor de código.
5. Exfiltração de Dados: Após as tentativas de configuração de persistência e acesso, um callback atrasado entrava em ação, transmitindo os metadados do host e os nomes das variáveis de ambiente coletadas para o servidor remoto via tráfego HTTP simples.

Impacto para o setor, usuários e mercado latino-americano

O impacto de um ataque de backdoor em ambientes de desenvolvimento é estrutural e sistêmico. Para o setor de tecnologia, este evento reforça a "falsa segurança" das extensões de terceiros. Muitas equipes de segurança monitoram ativamente a instalação de softwares executáveis, mas negligenciam os plugins de IDEs, que operam com amplas permissões para ler código-fonte, acessar variáveis de ambiente de produção e modificar arquivos do sistema.

Para os usuários afetados, as consequências vão muito além de um simples malware. A técnica de túnel reverso configurada pelo atacante permite contornar firewalls corporativos e redes NAT (Network Address Translation), concedendo acesso shell remoto direto ao computador do desenvolvedor. A partir daí, um invasor pode pivotar para outras máquinas na rede corporativa, roubar código-fonte proprietário ou injetar código malicioso nos repositórios da empresa.

No mercado latino-americano, que tem se consolidado como um polo de outsourcing de TI e desenvolvimento de software para corporações norte-americanas e europeias, esse risco é amplificado. Profissionais e squads alocados no Brasil, México e Colômbia frequentemente acessam infraestruturas críticas de clientes no exterior. O comprometimento de uma única máquina de um desenvolvedor terceiro por meio de uma extensão maliciosa pode servir como o vetor inicial de intrusão em uma corporação global.

Um ponto crítico para as equipes de Resposta a Incidentes (IR) é a limpeza pós-infecção. Remover a extensão do Cursor não mitiga a ameaça. Como o loader inseriu a chave svc-telemetry diretamente no nível do sistema operacional e configurou a persistência, o backdoor permanece ativo de forma autônoma. É exigida uma auditoria forense detalhada para remover artefatos ocultos e rotacionar todas as credenciais potencialmente expostas nas máquinas afetadas.

O que ainda não se sabe

Apesar da análise detalhada da carga útil, existem lacunas críticas na compreensão do evento:

• Taxa de Sucesso do Comprometimento: Não está claro quantos dos até 5.000 usuários expostos tiveram suas máquinas efetivamente comprometidas. A execução bem-sucedida do túnel SSH reverso dependia, na maioria dos casos, de o serviço SSH local já estar ativo e, muitas vezes, de o editor estar rodando com privilégios de administrador (cenário incomum, mas possível).
• Escopo da Exfiltração de Dados: A investigação confirmou que o loader coletou os nomes das variáveis de ambiente (revelando quais serviços e plataformas o desenvolvedor utiliza), mas não há evidências conclusivas ou confirmação técnica definitiva sobre se os valores exatos dessas variáveis (como chaves da AWS ou tokens do GCP) foram roubados ou interceptados posteriormente através do túnel estabelecido.
• Autoria e Motivação: A identidade do agente da ameaça e seu objetivo final permanecem ocultos. O uso de um endereço IP específico (134.209.82.225) foi derrubado em coordenação com provedores de hospedagem, mas a infraestrutura mais ampla e a afiliação do grupo atacante (seja cibercrime motivado por lucro ou espionagem estatal) ainda não foram atribuídas.

O que esperar a seguir

Nos próximos meses, o incidente forçará uma mudança de postura em toda a indústria de ferramentas para desenvolvedores.

• Auditoria Rigorosa em Marketplaces Menores: Editores que mantêm ecossistemas próprios, como o Cursor, implementarão políticas de verificação automatizada e análise estática de código muito mais severas, alinhando-se aos padrões de segurança de lojas como a da Microsoft ou da Apple.
• Ações de Remediação Constantes: Organizações realizarão varreduras em grande escala utilizando indicadores de comprometimento (IoCs), como a chave svc-telemetry, para garantir que nenhuma máquina na rede tenha um backdoor dormente.
• Rotação de Credenciais: Empresas exigirão a rotação compulsória de todas as chaves de API, tokens em nuvem e senhas que residiam nos ambientes de desenvolvimento das máquinas afetadas entre 29 de outubro e as datas subsequentes, visando neutralizar qualquer potencial acesso lateral. O Cursor já rotacionou suas próprias chaves criptográficas pós-incidente.

Perguntas frequentes

1. Minha extensão Claude Code no Visual Studio Code da Microsoft também está infectada? Não. A Microsoft e as análises forenses confirmaram que a extensão maliciosa foi distribuída exclusivamente através do Cursor Extension Marketplace. O ecossistema da Microsoft Visual Studio Marketplace e o repositório npm (@antropic-ai/claude-code) permaneceram seguros e não foram afetados pelo incidente.

2. Apenas desinstalar a extensão do Cursor resolve o problema de segurança? Não. O script malicioso realizou modificações no nível do sistema operacional. Ele alterou o arquivo authorized_keys adicionando a chave svc-telemetry, criou arquivos ocultos (como .stk_) e estabeleceu scripts de persistência para garantir que o backdoor sobrevivesse à reinicialização. É necessário realizar uma limpeza manual ou formatar o ambiente comprometido.

3. A Anthropic foi hackeada neste incidente? A Anthropic confirmou que seus sistemas internos não foram violados, assim como os laptops de seus funcionários. A versão adulterada (2.1.312 e 2.1.313) não foi criada pela Anthropic; o atacante conseguiu introduzir o pacote malicioso diretamente no marketplace de terceiros (Cursor) falsificando a identidade da extensão legítima.