Claude Code 2.1.313 tinha backdoor SSH oculto

Você atualizou e ganhou um invasor junto

Claude Code comprometido não é um alerta teórico, é um problema direto na sua máquina de trabalho. Se você instalou ou atualizou para a versão 2.1.313 da extensão oficial do Claude Code para VS Code via Cursor Marketplace, existe chance real de ter colocado para dentro um backdoor SSH persistente que mexe com authorized_keys, tenta ligar o acesso remoto e se mantém vivo depois de reiniciar. Não é um aviso de phishing distante, é código executando com as permissões do seu editor, com acesso aos seus arquivos, repositórios, chaves e tokens de desenvolvimento.

Eu testo extensão nova quase toda semana e o padrão se repete: a gente clica em instalar, confia no selo de oficial e esquece que aquele bundle tem poder total sobre o ambiente. Aqui o custo dessa confiança ficou explícito. O pacote malicioso não precisava que você clicasse em nada dentro da extensão, bastava o VS Code ou o Cursor carregar o módulo para o payload disparar. Para quem vive de código, isso muda a conta de risco de um jeito bem prático, porque o vetor não é um binário estranho, é a ferramenta que você usa para gerar código o dia inteiro.

O fato

O que aconteceu foi direto. Uma versão distribuída como oficial do Claude Code para VS Code, identificada como 2.1.313, circulou com código injetado no Cursor Marketplace. Depois da detecção, a Cursor removeu o release comprometido do marketplace e as versões 2.1.313 também foram puxadas do NPM e dos registros do VS Code. A recomendação operacional é tratar qualquer ambiente onde essa versão foi instalada como potencialmente comprometido e acionar resposta a incidentes, não apenas desinstalar e seguir a vida.

O payload tem como objetivo acesso interativo de longo prazo via SSH nos três sistemas principais, macOS, Linux e Windows, com lógica de persistência para cada um. A análise pública focou mais no macOS, onde a tentativa era configurar o backdoor SSH e garantir persistência, apontando também diferenças e alguns bugs de implementação nas outras plataformas. O ponto importante é que mesmo com falhas no código do atacante, as chaves e os mecanismos de persistência ainda são gravados na máquina.

Como funciona na visão de operador

Pensa em arquitetura de extensão de editor. Uma extensão de VS Code é basicamente Node.js com acesso amplo ao sistema do usuário. Nesse caso, o arquivo extension.js veio com uma função autoexecutável injetada no início do bundle minificado. O resto parecia normal, com strings do Claude Code e do VS Code, exports de activate e deactivate e código de interface. Só que o prefixo malicioso importava módulos padrão como child_process, fs, os, path, http e crypto e rodava assim que o Node carregava o arquivo, antes mesmo do activate normal. Ou seja, latência zero entre instalar e infectar, sem interação, sem telemetria visível.

O primeiro estágio prepara o acesso SSH. O script garante que o diretório .ssh existe na home do usuário e anexa uma chave pública Ed25519 controlada pelo atacante ao arquivo .ssh slash authorized_keys, ajustando permissões para 0700 no diretório e 0600 no arquivo. A chave usa o comentário svc-telemetry. Antes de gravar, ele verifica se a string svc-telemetry já está no arquivo, em vez de verificar a chave em si, e marca o status como added ou present. Com a chave no lugar, quem tiver a chave privada correspondente consegue autenticar como aquele usuário, desde que o daemon SSH esteja ativo.

É aqui que entra um detalhe técnico curioso que provavelmente salvou muita gente no Mac. A lógica tentava checar o estado do Remote Login e só tentava ativar se o retorno fosse Off. O problema é que, rodando como usuário padrão, o comando systemsetup trazia um erro de falta de privilégio de administrador e saía com status zero, em vez de retornar Off. Como o script só avançava para ligar o SSH se visse exatamente Off, ele pulava a etapa de ativação. Na prática, em um Mac sem SSH já ligado, o caminho de entrada falhava, mas a chave invasora e a persistência continuavam sendo instaladas. Em Linux e Windows a lógica segue outra trilha de serviços e tarefas agendadas, então não dá para assumir que o bug do macOS te protegeu em outro sistema.

Por que extensão é tão perigosa

Extensão de IDE roda com o seu usuário, lê seu disco, executa processos filhos, faz requisição de rede e persiste arquivos. Não tem sandbox real como em navegador. Quando você instala algo do marketplace, está essencialmente dando shell parcial para aquele fornecedor. Se o pipeline de build ou a conta de publicação é comprometida, milhares de desenvolvedores puxam o mesmo bundle envenenado em minutos, com acesso a segredos locais, código proprietário e acesso à nuvem via CLI. Custo de distribuição para o atacante é quase zero, latência de propagação é imediata e detecção é tardia porque o processo pai é legítimo.

O que isso muda na prática

Quem ganha com esse incidente é quem já trata estação de desenvolvedor como produção, com inventário de extensões, pinagem de versão e auditoria de artefatos. Quem perde é o fluxo de instalar tudo no modo automático, com sync de extensões entre máquinas e Cursor, VS Code, devcontainer e laptop pessoal misturados sem controle. Se sua empresa permite marketplace alternativo sem allowlist, esse caso mostra que o risco de supply chain não está só em pacote NPM ou imagem Docker, está no editor que tem suas chaves AWS no ambiente.

O que fazer agora é bem objetivo e precisa ser feito em ordem. Não adianta só remover a extensão e reinstalar por cima, porque a chave SSH e a persistência ficam para trás. O fluxo mínimo que eu faria em qualquer fleet seria este, máquina por máquina, sem pular etapa.

• Verifique se a versão 2.1.313 do Claude Code para VS Code foi instalada via Cursor, VS Code ou NPM e isole a máquina se houver confirmação.
• Inspecione o arquivo .ssh slash authorized_keys procurando pela string svc-telemetry e, mais importante, valide o fingerprint de chaves desconhecidas, pois o comentário pode ser alterado.
• Remova chaves estranhas, revise tarefas de persistência, serviços SSH ativados sem motivo e conexões recentes, e rotacione chaves SSH, tokens e credenciais de desenvolvimento usadas naquela estação.
• Reinstale a extensão apenas de fonte limpa e fixe a versão, além de registrar quais máquinas foram limpas para auditoria posterior.

Para times, vale congelar temporariamente atualizações automáticas dessa extensão, levantar inventário via MDM ou script de varredura do diretório de extensões e forçar rotação de segredos que passaram por estações expostas. Para dev solo, pelo menos cheque manualmente sua pasta .ssh hoje e olhe o histórico de instalação. É uma ação de cinco minutos que evita um acesso permanente que você nem percebe.

A tensão que fica

A dúvida real aqui não é se o backdoor era sofisticado, porque em partes ele era até desleixado, com checagem errada de permissão no macOS e lógica frágil de detecção por comentário. A dúvida é se nosso modelo atual de confiança em extensão escala. A gente aceita atualização silenciosa de ferramenta com acesso total porque é conveniente, mas não temos assinatura verificável ponta a ponta, nem diff visível do que mudou entre 2.1.312 e 2.1.313, nem isolamento decente. Isso resolve produtividade, mas só move o gargalo da segurança para o marketplace.

Também tem a conta do custo. Auditar cada extensão tem custo de tempo, manter allowlist irrita o time, travar versão atrasa feature. Mas qual é o custo de um SSH persistente em cem laptops com acesso a código fonte e infraestrutura? O bug no macOS que impediu a ativação do SSH em alguns casos foi sorte, não defesa. Da próxima vez o atacante acerta o systemsetup com sudo, usa LaunchDaemon correto ou abusa de outro binário vivo. Confiar que o malware vai errar não é estratégia.

No fundo, a reflexão de operador é incômoda. A ferramenta que deveria acelerar entrega virou vetor de invasão justamente porque tem privilégio demais e visibilidade de menos. Enquanto editor, marketplace e pipeline de publicação não tratarem extensão como código crítico, com build reproduzível e monitoramento de integridade, vamos continuar descobrindo backdoor depois que ele já persistiu.

Conclusão

Se você tocou na versão 2.1.313, assuma exposição, limpe chave SSH, remova persistência e rotacione segredos antes de voltar a codar. E fica a pergunta que vale levar para o time amanhã: quantas outras extensões com acesso total estão instaladas agora nas suas máquinas sem ninguém saber exatamente o que elas fazem?