5.000 desenvolvedores foram realmente hackeados? Qual foi o impacto do envenenamento do plugin do Cursor até agora?

Nota do autor: este artigo explica o que significa “até 5.000 pessoas potencialmente afetadas” no incidente de adulteração de uma extensão do Cursor. Também detalha a cadeia de ataque, os casos confirmados, os limites do risco para chaves API e os passos de verificação, para separar o que tem evidências do que é exagero.

Em 29 de outubro de 2026, uma versão adulterada da extensão Claude Code apareceu no marketplace do Cursor. Nos dias seguintes, começaram a circular manchetes como “5.000 desenvolvedores foram hackeados” e “vazamento em massa de chaves da API da Claude”. A realidade é outra: 5.000 é o limite máximo de usuários potencialmente afetados informado oficialmente pelo Cursor, não o número de invasões bem-sucedidas confirmadas.

Isso não significa minimizar o risco. O comunicado oficial do Cursor, a equipe de pesquisa de segurança da Microsoft e empresas como Phorion e Expel confirmaram o incidente e observaram atividades maliciosas em dispositivos de clientes. Neste artigo, vamos examinar seis etapas — “distribuição, execução, gravação, possibilidade de exploração, invasão efetiva e perda de dados” — para entender quais fatos foram confirmados e quais números ainda não foram divulgados.

O que você vai levar daqui: ao terminar a leitura, você poderá avaliar o impacto real da extensão adulterada para você e sua equipe, além de seguir as recomendações oficiais para verificar seu ambiente e substituir credenciais.

Resumo do ataque ao plugin do Cursor

Vamos começar pelos fatos já confirmados. O ponto central é entender o alcance do incidente: trata-se de um ataque à cadeia de suprimentos de uma ferramenta de desenvolvimento, não de uma invasão ao modelo Claude nem aos sistemas internos da Anthropic.

A Anthropic afirmou que não desenvolveu nem publicou essas compilações maliciosas e que o incidente não envolveu seus sistemas internos ou computadores de funcionários. Até 2 de novembro, ainda não havia uma conclusão pública sobre como o invasor conseguiu permissão para publicar compilações no marketplace do Cursor.

Linha do tempo do ataque ao plugin do Cursor

Há dois períodos que podem ser confundidos neste caso: a janela em que os pacotes maliciosos estavam disponíveis para download no marketplace e o momento em que o código malicioso foi executado nos dispositivos onde já estava instalado. O segundo pode ocorrer muito depois do primeiro: remover o plugin da loja não significa que os dispositivos locais já estejam seguros.

Inicialmente, também houve relatos de que o Open VSX teria sido atacado. A OpenSourceMalware corrigiu essa informação mais tarde, e a Socket não encontrou as versões maliciosas correspondentes ao verificar os registros do Open VSX. Até agora, o único canal confirmado como alvo do ataque é o Cursor Marketplace.

Como funciona a contaminação de uma extensão do Cursor: de um carregador de 66 linhas a um túnel SSH reverso

Segundo análises da Phorion e da OpenSourceMalware, os atacantes inseriram um carregador JavaScript malicioso de cerca de 66 linhas no início do arquivo extension.js de uma extensão legítima, antes do código normal. Ele era acionado assim que o módulo da extensão carregava, sem que o usuário precisasse enviar uma mensagem ao Claude ou autorizar qualquer tarefa de programação. A interface e as funções do Claude Code continuavam funcionando normalmente, e alguns erros eram tratados silenciosamente, dificultando a percepção do ataque.

A cadeia de ataque pode ser resumida em seis etapas:

1. Coleta de informações do dispositivo: nome do host, nome de usuário, sistema operacional e arquitetura da CPU, diretório pessoal, diretório de trabalho, e-mail global do Git, IP público, entre outros dados.
2. Inserção de uma chave SSH autorizada: gravação de uma chave pública controlada pelo atacante no arquivo authorized_keys do usuário, identificada como svc-telemetry.
3. Tentativa de ativar o serviço SSH: se o dispositivo permitir login por SSH, o atacante poderá usar a chave inserida para acessar o sistema.
4. Criação de um túnel SSH reverso: o dispositivo da vítima inicia uma conexão com o servidor do atacante (TCP 22), que é encaminhada de volta ao serviço SSH local, contornando algumas restrições de entrada.
5. Instalação de mecanismos de persistência: no macOS e no Windows, é configurada uma reconexão automática após o login; no Linux, é usado crontab @reboot. Assim, o backdoor pode funcionar sem depender da própria extensão. Se a conexão falhar, uma nova tentativa é feita a cada 60 segundos, aproximadamente.
6. Envio do status de execução: um beacon HTTP na porta TCP 8099 envia ao servidor as informações do dispositivo e os resultados de cada etapa.

Por que a contaminação da extensão do Cursor não é uma injeção de comando

Ao ver que houve um problema com o Claude Code, muita gente pensa logo que o modelo foi manipulado por um comando malicioso. Não foi o caso. Trata-se de um ataque típico de execução de código em uma extensão: a lógica maliciosa não tem relação com as respostas do modelo. O princípio seria o mesmo com qualquer outra extensão de IDE adulterada.

Por isso, discutir a segurança do modelo Claude em si não ajuda a entender esse caso. O problema revelado é outro: quando um canal de distribuição de extensões para ferramentas de desenvolvimento é usado indevidamente, a cadeia de confiança se rompe.

As duas falhas de implementação no código malicioso

Erros no código reduziram o potencial de dano desse ataque. No macOS, o código malicioso consultava o status do Login Remoto sem privilégios de administrador. Por isso, o sistema retornava um erro de permissão, e não a informação de que o serviço estava desativado. Como o programa só tentava ativar o SSH quando identificava explicitamente que ele estava desativado, essa etapa falhava em muitos Macs nos quais o SSH não estava habilitado.

No Windows, ao instalar o OpenSSH Server, o código invocava por engano o caminho /bin/sh, típico de sistemas Unix e inexistente em um ambiente Windows padrão.

Mas ter falhas não significa que o ataque fosse inofensivo. O código malicioso ainda conseguia gravar a chave pública, gerar scripts de persistência, iniciar conexões de rede e enviar informações do dispositivo. O risco era bem maior para dispositivos que já estavam com o SSH ativado. Em entrevista à WIRED, Calum Hall, cofundador da Phorion, também afirmou que, se tivesse sido implementado corretamente, o ataque poderia ter criado um ponto de entrada muito perigoso.

5.000 desenvolvedores foram invadidos? Os 6 níveis de impacto da adulteração da extensão do Cursor

O número “5.000” vem do anúncio inicial do Cursor, publicado em 29 de outubro: “At most 5,000 users were affected”, ou seja, no máximo 5.000 usuários foram afetados. Esse é o limite informado pela própria empresa, não o número de invasões confirmado de forma independente por uma organização de segurança. O anúncio inicial mencionava apenas a versão 2.1.313; depois, foi atualizado para incluir a 2.1.312. A empresa não divulgou quantos usuários correspondiam a cada versão nem apresentou uma distribuição completa dos números após a revisão.

Ao dividir o impacto em seis níveis, fica mais fácil distinguir o que foi confirmado do que ainda é especulação:

A diferença entre os dois lados do gráfico mostra a distância entre as manchetes e as evidências. Quanto mais abaixo no funil, menos evidências públicas existem. Até o momento, não há provas que sustentem as afirmações de que “5.000 computadores foram totalmente controlados” ou que “as chaves API de 5.000 pessoas foram roubadas”.

O que os 4 casos reais da Expel mostram

Entre 29 e 30 de outubro, a Expel lidou com 4 incidentes relacionados, envolvendo 4 clientes e um Mac em cada caso. Três máquinas usavam o CrowdStrike Falcon, e uma usava o Microsoft Defender for Endpoint. Nos 4 incidentes, houve conexões de rede com o IP do servidor dos atacantes. Isso mostra que o problema já foi além da análise de código em laboratório.

O caso mais significativo é o da execução tardia. Às 12h44 de 30 de outubro, no horário de Pequim, um usuário entrou no Mac e abriu o Cursor. Um minuto depois, começou a atividade maliciosa e, às 22h29, ainda havia conexões com o IP dos atacantes — quase 10 horas depois. A essa altura, o pacote malicioso já havia sido removido do marketplace. Uma explicação plausível é que o pacote de instalação tenha sido baixado durante o período de exposição e só tenha sido ativado quando o usuário abriu o Cursor novamente.

Esses dados têm limites claros: os 4 casos não significam que apenas 4 dispositivos foram comprometidos no mundo, e não é possível calcular uma taxa de infecção dividindo 4 por 5.000. Detectar um túnel SSH também não significa que os atacantes conseguiram fazer login. A Phorion também encontrou amostras em Macs de clientes, mas não está claro se há sobreposição com os casos da Expel, então os números não podem ser simplesmente somados. A Expel ainda encontrou uma máquina com um processo de túnel malicioso, mas sem o marcador de chave pública svc-telemetry — sinal de que buscar apenas um marcador pode deixar casos passar despercebidos.

Limites do risco para chaves API no comprometimento de um plugin do Cursor

O código malicioso selecionava até 40 variáveis de ambiente cujos nomes continham KEY, TOKEN, SECRET, PASS, AWS ou GCP. Se a máquina tivesse, por exemplo, uma variável OPENAI_API_KEY, o atacante poderia saber que ela usava o serviço correspondente. Mas os pesquisadores confirmaram que o envio inicial incluía apenas os nomes das variáveis, não seus valores.

Portanto, a forma precisa de descrever o risco é: o código de ataque conseguia identificar categorias de configurações sensíveis. Se o backdoor fosse de fato explorado, o atacante poderia também ler credenciais locais e código-fonte. Quanto ao número de chaves API efetivamente roubadas, não há dados públicos até o momento. Dizer que “todas as chaves API dos usuários foram roubadas” é confundir capacidade com resultado. Ainda assim, como os limites do risco não estão claros, faz sentido trocar as credenciais como medida preventiva.

Análise dos impactos do comprometimento do plugin do Cursor

Impacto para desenvolvedores

• Desinstalar o plugin não basta: o comunicado oficial alerta que apenas desinstalar ou atualizar para a versão 2.1.314 não necessariamente remove chaves públicas SSH, itens de inicialização e scripts em segundo plano que já tenham sido adicionados.
• O código ainda pode ser executado após a remoção do plugin: o caso de execução tardia relatado pela Expel mostra que usuários que só abriram o Cursor depois da remoção também precisam verificar seus dispositivos.
• Máquinas com SSH sempre ativado correm mais risco: computadores de desenvolvimento costumam manter o Remote Login ativo para depuração remota, o que evita justamente a falha de implementação do código malicioso.
• A exposição de credenciais foi mapeada: mesmo que o backdoor não tenha sido explorado com sucesso, o atacante pode já saber quais serviços de nuvem e APIs você usa.

Impacto para equipes e para o setor

• A distribuição de plugins se tornou uma nova superfície de ataque: versões da mesma extensão em marketplaces diferentes podem ter origens distintas. Na análise, é preciso considerar a origem da instalação e os hashes dos arquivos, não apenas o número da versão.
• As permissões de terminal concedidas a ferramentas de programação com IA precisam ser reavaliadas: plugins de IDE geralmente são executados com as permissões do usuário, podendo ler e gravar arquivos no diretório pessoal e estabelecer conexões de rede. As empresas devem incluí-los no controle de endpoints.
• A resposta ao incidente precisa cobrir o ciclo de vida das credenciais: é preciso avaliar os repositórios, chaves API, credenciais de nuvem e tokens de sessão aos quais os dispositivos afetados têm acesso. Quanto mais distribuídas estiverem as chaves usadas nos projetos, maior será o custo de substituí-las.

Como verificar o envenenamento de uma extensão do Cursor e fazer a rotação de credenciais

Primeiro, use os scripts de verificação e correção para macOS e Windows disponíveis no comunicado oficial do Cursor. Os indicadores e comandos abaixo ajudam a entender e investigar o problema, mas não substituem os scripts oficiais nem a análise dos logs.

Primeiro passo: verificação rápida na máquina (exemplo no macOS)

# 1. 检查授权公钥中是否有攻击者标记（注意：没找到不代表安全，可能漏报）
grep -n "svc-telemetry" ~/.ssh/authorized_keys

# 2. 检查持久化文件与启动项
ls -la ~/.config/.smt ~/.config/.smtk ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null

# 3. 检查是否存在与恶意服务器的连接
lsof -nP -i | grep "134.209.82.225"

# 4. 确认 Remote Login 状态（需要管理员权限）
sudo systemsetup -getremotelogin

No Windows, use schtasks /query /tn SysMon para verificar a tarefa agendada e procure sysmon.cmd na pasta de inicialização. Se encontrar qualquer um desses indicadores, preserve as evidências, isole o dispositivo e faça a limpeza com os scripts oficiais. Se não for possível restaurar a confiabilidade do dispositivo, considere reinstalar o sistema e fazer a rotação das credenciais em outro dispositivo confiável.

Etapa 2: identificar os nomes das variáveis de credenciais expostas

O script abaixo usa as mesmas palavras-chave do código malicioso para filtrar variáveis de ambiente. Ele imprime apenas os nomes, sem mostrar os valores, ajudando você a listar as credenciais que precisam ser rotacionadas. Depois da rotação, faça uma chamada simples à API para confirmar que a nova chave funciona:

import os, re, openai

# 与恶意代码相同的关键词，列出可能被“摸底”的变量名
pattern = re.compile(r"KEY|TOKEN|SECRET|PASS|AWS|GCP")
print([k for k in os.environ if pattern.search(k.upper())])

# 在可信设备上轮换后，用新 Key 验证调用
client = openai.OpenAI(
    api_key=os.environ["NEW_API_KEY"],
    base_url="https://api.apiyi.com/v1"  # APIYI OpenAI 兼容接口
)
r = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "ping"}]
)
print(r.choices[0].message.content)

import os
import re
import openai
from typing import List

KEYWORDS = re.compile(r"KEY|TOKEN|SECRET|PASS|AWS|GCP")

def list_sensitive_env_names(limit: int = 40) -> List[str]:
    """只返回疑似凭证的环境变量名称，绝不输出值。
    limit 与恶意代码的筛选上限保持一致，用于还原攻击者可能看到的视图。"""
    names = [k for k in os.environ if KEYWORDS.search(k.upper())]
    return sorted(names)[:limit]

def verify_new_key(model: str = "gpt-4o-mini") -> bool:
    """轮换后验证新 Key 是否可正常调用"""
    client = openai.OpenAI(
        api_key=os.environ.get("NEW_API_KEY", ""),
        base_url="https://api.apiyi.com/v1"
    )
    try:
        resp = client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": "ping"}],
            max_tokens=10
        )
        return bool(resp.choices[0].message.content)
    except Exception as e:
        print(f"验证失败: {e}")
        return False

if __name__ == "__main__":
    print("可能暴露给攻击者的变量名：")
    for name in list_sensitive_env_names():
        print("  -", name)
    print("新 Key 验证结果：", verify_new_key())

Terceiro passo: substitua as credenciais por ordem de prioridade

🎯 Dica técnica: se o projeto se conecta diretamente a várias plataformas, como OpenAI, Claude e Gemini, após um incidente será necessário acessar cada painel para revogar e recriar as chaves. A recomendação oficial é centralizar as invocações dos modelos na APIYI apiyi.com: uma única chave dá acesso a modelos de vários provedores, com uma interface compatível com a OpenAI. Na hora de substituir a chave, basta alterar uma configuração. Isso também facilita o acompanhamento centralizado do uso e a identificação de gastos suspeitos.

Perguntas frequentes

Principais pontos sobre a extensão maliciosa do Cursor

• Natureza do incidente: o marketplace do Cursor distribuiu uma extensão adulterada. Trata-se de um ataque à cadeia de suprimentos, não de uma vulnerabilidade no modelo Claude.
• O que significa 5.000: esse é o limite máximo de usuários potencialmente afetados informado oficialmente, não o número confirmado de invasões.
• O que foi confirmado: uma organização independente observou atividade maliciosa e conexões externas em um Mac real.
• O que não foi divulgado: o número de acessos remotos bem-sucedidos, a quantidade de chaves roubadas e as perdas financeiras.
• Principal risco: a ameaça ainda pode ser acionada depois da remoção da extensão do marketplace. Desinstalá-la não garante a eliminação da backdoor.
• Como agir: execute o script oficial, troque as credenciais em um dispositivo confiável e use APIYI apiyi.com para reduzir o número de chaves.

Resumo

Os principais pontos do incidente com a extensão maliciosa do Cursor são:

1. Diferencie manchetes de evidências: “até 5.000 pessoas afetadas” está bem longe de “5.000 pessoas invadidas”. Por enquanto, as evidências públicas confirmam que houve casos reais de execução do código malicioso.
2. O ataque existiu, mas teve limitações: o código malicioso tinha recursos de backdoor e persistência, mas falhas na implementação para macOS e Windows reduziram a taxa de sucesso dos acessos remotos.
3. Uma única verificação não basta: combine a análise da origem da instalação, dos hashes de arquivos, processos, conexões de rede e itens de inicialização. Buscar apenas por svc-telemetry pode deixar passar sinais do ataque.

Se você usou a extensão Claude Code pelo marketplace do Cursor entre 29 e 30 de outubro, primeiro faça uma verificação seguindo as orientações oficiais e depois troque suas credenciais por ordem de prioridade. Quanto às APIs de modelos, você pode aproveitar para reunir as chaves dispersas no APIYI apiyi.com. Isso facilita bastante uma futura troca emergencial.

📚 Referências

1. Aviso oficial de segurança da Cursor: cronologia do incidente, versões, hashes dos arquivos maliciosos e scripts de limpeza
2. Link: cursor.com/blog/claude-code-extension-security-notice

3. Observação: comece a verificação por este aviso, que inclui scripts de correção para macOS e Windows

4. Microsoft Security Research: análise da cadeia de ataque da extensão maliciosa Claude Code

5. Link: microsoft.com/en-us/security/blog/2026/10/30/inside-malicious-claude-code-branded-cursor-extension-persistent-ssh-backdoor/

6. Observação: consulte os detalhes sobre os limites da cadeia de suprimentos, o mecanismo SSH e a persistência

7. Phorion: Official Claude Code Extension Compromise

8. Link: phorion.io/blog/offical-claude-code-vsx-compromise/

9. Observação: detalhes técnicos sobre o carregador de 66 linhas, diferenças entre plataformas e falhas no código

10. Expel: Fake Claude Code extensions in Cursor

11. Link: expel.com/blog/blog-fake-claude-code-extension-cursor-ssh-backdoor/

12. Observação: 4 incidentes reais envolvendo clientes e casos de execução atrasada

13. Socket: Cursor Removes Malicious Claude Code Extension

14. Link: socket.dev/blog/claude-code-extension-compromise
15. Observação: verificação de registros do Open VSX e do npm, com correções de informações divulgadas inicialmente

Autor: equipe técnica da APIYI
Troca de experiências técnicas: entre em contato conosco pela página inicial da APIYI em apiyi.com. Para mais informações sobre integração, acesse a central de documentação em docs.apiyi.com

Artigos relacionados

• Extensão do Claude Code comprometida: backdoor na versão 2.1.313 e 5 passos para verificar e remover: Em 29/10, o Claude Code oficial 2.1.312 e 2.1.313 no Cursor Marketplace foi trocado por versões com backdoor SSH, expondo até 5.000 usuários; em 5 passos, verifique a chave pública svc-telemetry, remova LaunchAgent e tarefas agendadas, atualize para 2.1.314+ e troque credenciais GitHub, de nuvem e APIYI.
• Claude Max foi renomeado para Ultra: o limite de 5 horas foi removido? Entenda as 3 mudanças primeiro: Claude Max 20x passa a chamar-se Ultra e Max 5x, Max, sem alteração de preço; contas Ultra verificadas deixam de ter limite de 5 horas, mantendo o limite semanal; uma tabela comparativa, 3 passos de autoavaliação e cálculos ajudam a decidir se deve mudar de plano.