GitHub hackeado via extensão VS Code: o caso TeamPCP

18 minutos. É o tempo que a versão 18.95.0 do Nx Console ficou disponível no Visual Studio Code Marketplace antes de ser removida — tempo mais do que suficiente para que o grupo TeamPCP comprometesse um funcionário do GitHub e exfiltrasse cerca de 3.800 repositórios internos da empresa. O incidente, confirmado pelo GitHub em 20 de maio de 2026, é um dos casos mais emblemáticos de ataque à cadeia de fornecimento de software do ano.

O que é o Nx Console e por que isso importa para você

O Nx Console é uma extensão legítima e muito popular do VS Code, usada por desenvolvedores que trabalham com o framework Nx para monorepos. Tem centenas de milhares de instalações ativas. Ou seja: não estamos falando de uma extensão obscura que alguém instalou por descuido — é uma ferramenta mainstream, confiável, com histórico limpo.

É exatamente esse o ponto. Atacar uma extensão popular significa comprometer de uma vez um número enorme de targets qualificados: desenvolvedores com acesso a tokens de repositório, pipelines de CI/CD e infraestrutura corporativa. Quem instala o Nx Console não é um usuário leigo — é alguém com credenciais valiosas.

Como o ataque funcionou, passo a passo

A cadeia de comprometimento, segundo análise do Bleeping Computer e da Help Net Security, seguiu este caminho:

1. Publicação da extensão maliciosa: em 18 de maio, os atacantes publicaram a versão 18.95.0 no Marketplace, substituindo (ou se passando pelo pacote oficial). Ficou no ar entre 11 e 18 minutos.
2. Execução automática ao iniciar o VS Code: toda vez que a extensão carregava, ela rodava silenciosamente um comando npx apontando para um commit específico no repositório oficial nrwl/nx no GitHub.
3. Download e execução do payload oculto: esse commit plantado instalava e executava um pacote chamado nx-next, disfarçado como parte de uma configuração de MCP (uma tarefa rotineira no ecossistema Nx). O real objetivo do nx-next: roubar tokens de acesso ao GitHub e outras credenciais do ambiente.
4. Exfiltração: com o token capturado do dispositivo de um funcionário do GitHub, os atacantes acessaram e clonaram repositórios internos da empresa.

O vetor é especialmente sofisticado porque o código malicioso não estava diretamente na extensão: ela apenas chamava código de outro lugar (o commit plantado no repositório legítimo do Nx). Isso dificulta detecção por scanners que analisam só o pacote em si.

Quem é o TeamPCP

O TeamPCP — rastreado pelo Google Threat Intelligence Group como UNC6780 — é um grupo criminoso especializado em supply chain attacks contra ferramentas de desenvolvimento e infraestrutura open source. Antes do GitHub, o grupo já havia comprometido:

• O scanner de segurança Trivy, da Aqua Security
• O KICS, da Checkmarx
• A biblioteca LiteLLM
• O Telnyx SDK
• Pacotes da TanStack e da MistralAI

O padrão é consistente: alvos são desenvolvedores e times de segurança — pessoas com acesso privilegiado. Os 3.800 repositórios roubados do GitHub foram colocados à venda por US$ 95.000, numa operação conjunta com o grupo LAPSUS$. O GitHub confirmou que o número é "consistente com a investigação interna".

O que o GitHub perdeu — e o que foi preservado

O GitHub foi claro: dados de clientes, repositórios de usuários e contas enterprise não foram afetados. O comprometimento ficou restrito ao ambiente corporativo interno da empresa — código-fonte de sistemas internos, ferramentas e infraestrutura própria.

Isso não é pouca coisa. Código interno pode revelar arquitetura, fluxos de autenticação, dependências críticas e potenciais pontos fracos que um adversário persistente pode explorar meses depois. Não é um breach de dados de usuário, mas é um vetor para ataques futuros mais direcionados.

Esse tipo de incidente tem paralelo direto com o que aconteceu com a Trellix, quando o grupo RansomHouse roubou código-fonte de uma empresa de segurança — demonstrando que nem quem protege os outros está imune.

Não é o primeiro ataque assim — e não será o último

Esse padrão de comprometer a ferramenta do desenvolvedor para chegar ao alvo final vem crescendo. Em abril deste ano, cobri aqui no blog o ataque de supply chain ao JDownloader via pacote Python envenenado — mesma lógica: comprometer uma ferramenta confiável para escalar acesso.

A diferença aqui é a sofisticação: o código malicioso não estava dentro do pacote publicado, mas era baixado dinamicamente de uma fonte aparentemente legítima (o próprio repositório do Nx no GitHub). Isso torna a detecção muito mais difícil para soluções tradicionais de análise estática.

O que você deve fazer agora

Se você usa o Nx Console no VS Code, o primeiro passo é imediato:

• Atualize para a versão 18.100.0 ou superior, confirmada como livre do payload malicioso.
• Verifique o histórico de tokens GitHub associados ao seu dispositivo em Settings → Developer Settings → Personal Access Tokens e revogue qualquer token suspeito.
• Se você instalou a extensão entre 17 e 19 de maio de 2026, trate suas credenciais como comprometidas: rotacione tokens, revise logs de acesso ao GitHub e audite repositórios acessados no período.
• Considere restringir quais extensões do VS Code têm permissão para rodar scripts de rede no startup — políticas de extensão corporativa existem exatamente para isso.

Para times que gerenciam múltiplas estações de trabalho de desenvolvedores, vale revisar os logs de execução do VS Code e do terminal. A auditoria de logs com PowerShell pode ajudar a identificar execuções suspeitas de npx fora do fluxo normal de trabalho.

A lição maior

Confiar em uma extensão porque ela é popular e tem histórico limpo é uma heurística razoável — mas o TeamPCP demonstrou que basta uma janela de 18 minutos para transformar essa confiança em vetor de ataque. A superfície de risco do desenvolvedor moderno inclui cada plugin, cada dependência, cada package manager invocado no terminal.

O GitHub sobreviveu ao incident sem expor dados de usuários. Outros não terão tanta sorte. Se você administra uma equipe de desenvolvimento, esse é o momento de revisar a política de extensões aprovadas — antes que alguém na sua empresa seja o próximo funcionário com um token capturado.

Se você foi afetado ou quer discutir como implementar controles de extensão no seu ambiente, conta nos comentários.