TeamPCP: uma assinatura válida que certificou malware em cripto

Cripto foi construída sobre uma promessa: "não confie, verifique". Em maio de 2026, um verme de npm produziu uma assinatura criptográfica perfeitamente válida — que certificava malware. O grupo TeamPCP envenenou a Nx Console, a extensão oficial do VS Code (2,2 milhões de instalações), e desencadeou o Mini Shai-Hulud, o primeiro verme documentado que se autopropaga com provenance (procedência assinada) SLSA Build Level 3 autêntica. O GitHub confirmou a exfiltração de cerca de 3.800 de seus repositórios internos em menos de 20 minutos. Mas o dado que importa para cripto não é esse: é que a atestação criptográfica — a mesma classe de prova sobre a qual se ergue toda a confiança on-chain — deixou de garantir qualquer coisa. E não é um caso isolado: é o último elo de uma linha de oito anos de ataques à cadeia de suprimentos direcionados especificamente contra cripto. Dizemos isso sem alarmismo: o payload varre rotas de wallets, mas até 1 de junho não há postmortem que documente fundos DeFi roubados por esta campanha. É um vetor confirmado, não uma perda consumada — e o histórico anterior explica por que convém levá-lo a sério.

O que aconteceu exatamente em maio de 2026?

Em 11 de maio de 2026, as equipes de segurança da cadeia de suprimentos detectaram a primeira onda de um verme que infectava pacotes de npm: mais de 170 pacotes comprometidos, entre eles componentes de projetos amplamente utilizados como TanStack e bibliotecas da Mistral AI. Em 12 de maio, o código-fonte do verme apareceu publicado brevemente em um repositório público do GitHub antes de ser removido — material que serviu de base para as análises forenses posteriores.

O salto qualitativo ocorreu em 18 de maio. O TeamPCP publicou uma versão maliciosa (v18.95.0) da Nx Console, a extensão oficial do VS Code para o monorepo Nx, com mais de 2,2 milhões de instalações. A versão envenenada esteve disponível no VS Code Marketplace por uma janela muito curta: o postmortem oficial da Nx a estima em 11 minutos e o alerta da CISA em 18 — em qualquer caso, menos de 20 minutos. No Open VSX (o registro aberto usado por editores como Cursor ou VSCodium), a janela chegou a cerca de 36 minutos. Tempo mais que suficiente para que a atualização automática a empurrasse para um número desconhecido de máquinas de desenvolvedores.

Em 19 de maio, o GitHub confirmou a exfiltração de aproximadamente 3.800 de seus próprios repositórios internos — um número reivindicado pelo atacante e validado de forma provisória pela plataforma. O GitHub esclareceu que os repositórios de clientes não foram afetados. No mesmo dia, uma segunda onda do verme foi lançada contra os pacotes da família @antv (a suíte de visualização de dados da AntDesign), elevando para mais de 500 os pacotes comprometidos nessa leva. O número de 518 milhões que circulou corresponde aos downloads históricos totais acumulados pelos pacotes afetados, não a downloads do malware.

Como funcionou o ataque, passo a passo?

A elegância do ataque está em encadear confiança legítima em cada elo. A sequência, reconstruída a partir dos boletins da StepSecurity, OX Security e do postmortem da Nx:

1. Extensão envenenada. O desenvolvedor instala ou atualiza a Nx Console a partir do Marketplace oficial. A extensão possui assinatura válida e procede do publisher correto. Ao ser ativada, a versão maliciosa executa código na máquina do desenvolvedor com os mesmos privilégios de sua sessão de editor.
2. Roubo do token de CI/CD. Muitos repositórios usam GitHub Actions com tokens OIDC (OpenID Connect: credenciais de curta duração que um pipeline obtém para se autenticar sem segredos estáticos) e tokens de publicação de npm. O payload busca essas credenciais no ambiente e nos arquivos de configuração do projeto: variáveis de ambiente, arquivos .npmrc, tokens de Actions em cache.
3. Propagação do verme. Com um token de publicação de npm válido, o malware não precisa esperar por outra vítima humana. Ele republica versões troyanizadas dos pacotes que esse token controla, e esses pacotes, por sua vez, infectam quem os instalar. É a propriedade que transforma um incidente pontual em um verme: autorreplicação através da rede de dependências.
4. Assinatura de procedência válida. Aqui está a inovação assustadora. O Mini Shai-Hulud gera atestações SLSA Build Level 3 autênticas para os pacotes maliciosos. A cadeia de procedência que o npm exibe como prova de que um pacote foi construído em um pipeline confiável estava criptograficamente correta — apenas certificava malware. A assinatura não foi falsificada: foi emitida por um pipeline sequestrado.
5. Varredura de credenciais e wallets. O payload escaneia o disco em busca de rotas de wallets de criptomoedas — arquivos de Bitcoin, Ethereum e Monero, e diretórios de aplicações como Exodus, Electrum e Atomic — além de chaves de CI/CD, tokens de nuvem e segredos de implantação. Isso é o que transforma um ataque genérico à cadeia de suprimentos em uma ameaça específica para quem desenvolve em Web3.

Por que este ataque é especificamente perigoso para devs Web3?

Um desenvolvedor de aplicações tradicionais que sofre este comprometimento perde, no pior caso, segredos corporativos e acesso à infraestrutura da empresa. Um desenvolvedor Web3 possui na mesma máquina, e frequentemente na mesma árvore de projeto, ativos que são dinheiro ao portador.

O equivalente Web3 de "roubar a senha de produção" é roubar a chave privada que assina a implantação de um contrato, ou a seed de uma wallet de tesouraria de um protocolo. Não há departamento de fraude que reverta a transação nem suporte que congele a conta: se a chave vazar e o atacante assinar, os fundos se foram. As rotas que o payload do Mini Shai-Hulud rastreia — Exodus, Electrum, Atomic, chaves de Ethereum e Bitcoin — são exatamente as que um dev cripto tem à mão para testar, implantar e operar.

A isso soma-se o risco de pipeline. Se o token de publicação de npm da sua biblioteca vazar, o atacante não rouba você: ele troyaniza seu pacote e o entrega a todos os seus usuários com a sua assinatura. Para um projeto DeFi cuja biblioteca de SDK é consumida por outros dapps, isso significa tornar-se, sem saber, o vetor que compromete terceiros. O dano reputacional e de confiança é difícil de reverter.

A distinção honesta: até 1 de junho de 2026 não existe um postmortem público que documente fundos DeFi subtraídos atribuíveis a esta campanha. O vetor está confirmado pela análise do payload; o roubo de criptoativos através dele é um risco ativo, não um fato relatado. Tratá-lo como iminente é prudente; afirmar que já esvaziou tesourarias é falso.

Isso é novo? A linhagem de ataques à cadeia de suprimentos contra cripto

Não. O que torna o Mini Shai-Hulud relevante não é o fato de ser inédito, mas sim ser o degrau mais alto de uma escada que o setor cripto vem subindo desde 2018. A cadeia de suprimentos de software — os pacotes de npm, as bibliotecas que assinam transações, os SDKs que carregam os dapps — tem sido um alvo recorrente precisamente porque se conecta diretamente ao dinheiro. Estes são os marcos:

A coluna de roubos ensina duas coisas. Primeira: a escala e o dano não andam de mãos dadas. O ataque de setembro de 2025 atingiu pacotes com 2,6 bilhões de downloads semanais e levou centavos; a Ledger drenou mais de meio milhão de dólares em menos de duas horas com uma biblioteca muito menor, porque estava conectada diretamente às assinaturas de dapps. O que decide o saque não é quantas máquinas você infecta, mas quantas possuem uma chave que movimenta dinheiro ao alcance. Segunda: a sofisticação escala. O Copay esperava passivamente por uma vítima rica; o Shai-Hulud se autopropaga; o Mini Shai-Hulud, além disso, assina seu próprio malware com uma atestação que o sistema aceita como boa.

O paradoxo da confiança: quando uma assinatura válida certifica malware

Aqui está o golpe que deveria incomodar o setor cripto mais do que o roubo de 3.800 repositórios. A indústria de software construiu o SLSA e as atestações de procedência do npm como resposta ao SolarWinds: a ideia era que você pudesse verificar criptograficamente que um pacote foi construído em um pipeline confiável, sem ter que confiar na palavra de ninguém. É, ponto por ponto, a mesma filosofia que sustenta o cripto — "don't trust, verify", a verificação substitui a confiança.

O Mini Shai-Hulud não quebrou essa verificação: ele a cooptou. Seus pacotes maliciosos carregam uma assinatura de procedência SLSA Build Level 3 autêntica, criptograficamente correta, porque foi emitida por um pipeline real — apenas sequestrado. A verificação passa. A prova é válida. E certifica malware. A lição é amarga e se aplica diretamente a qualquer sistema baseado em atestação, incluindo boa parte da estrutura on-chain: uma assinatura válida demonstra de onde algo vem, nunca que seja honesto. Quando confundimos "verificado" com "seguro", a criptografia deixa de nos proteger e começa a nos dar uma falsa tranquilidade assinada.

Em que se diferencia do SolarWinds?

O ataque ao SolarWinds (2020) é a referência obrigatória da cadeia de suprimentos de software. A comparação ajuda a medir o quanto o patamar mudou em seis anos.

Duas diferenças importam mais que as outras. A primeira é a autorreplicação: o SolarWinds dependia de que as vítimas instalassem uma atualização específica; o Mini Shai-Hulud se propaga sozinho cada vez que captura um token de publicação, sem esperar intervenção humana. A segunda é a procedência válida: a indústria construiu o SLSA e as atestações do npm precisamente como resposta ao SolarWinds, para que se pudesse verificar que um pacote veio de um pipeline confiável. O TeamPCP não quebrou essa defesa — ele a cooptou. Uma assinatura de procedência autêntica deixa de ser garantia quando o pipeline que a emite já está comprometido.

Quem é o TeamPCP e por que a atribuição importa?

O Google Threat Intelligence (Mandiant) rastreia o grupo como UNC6780. Diferente do SolarWinds, atribuído a espionagem de estado-nação, o TeamPCP tem motivação financeira: monetiza os acessos através do grupo de ransomware Vect, segundo a análise coletada pelo SANS Internet Storm Center e CSA Labs. O grupo permanece latente desde aproximadamente 24 de maio; não há novas ondas datadas após essa data que possam ser dadas como confirmadas.

A cronologia institucional fechou o cerco no final de maio. Em 27 de maio, a vulnerabilidade da Nx Console — registrada como CVE-2026-48027, com uma pontuação CVSS de 9,8 no NVD e 9,4 na avaliação da CISA — foi adicionada ao catálogo KEV (Known Exploited Vulnerabilities) da CISA, a lista de falhas com exploração ativa confirmada. Em 28 de maio, a CISA emitiu um alerta formal sobre os comprometimentos da Nx Console e dos repositórios do GitHub. Separadamente, o CERT-EU documentou a Comissão Europeia como vítima downstream através de um comprometimento anterior do mesmo grupo na ferramenta Trivy (março de 2026), o que mostra o alcance institucional do ator além do ecossistema cripto.

Como audito meu ambiente de desenvolvimento Web3 agora mesmo?

Este é o bloco acionável. Se você desenvolve em Web3 e usa VS Code, npm ou pipelines de CI/CD, percorra estes pontos antes de continuar lendo o resto.

• Audite as extensões do VS Code instaladas. Revise a lista de extensões e suas versões. Se você tem a Nx Console, confirme que não está na v18.95.0; a Nx publicou uma versão limpa após o incidente. Além desta extensão específica, desative a atualização automática de extensões em ambientes onde você manipula chaves sensíveis: a atualização silenciosa foi precisamente o que distribuiu o payload em menos de 20 minutos.
• Verifique a procedência de suas dependências npm — com ceticismo. Execute npm audit signatures e revise as atestações de procedência, mas assuma que uma procedência válida já não é prova suficiente por si só. Uma pista útil relatada neste caso: na onda da @antv de 19 de maio, foram publicadas mais de 300 versões em uma rajada de cerca de 22 minutos; ferramentas de análise de dependências como Socket.dev ou Phylum detectam esse padrão de publicação massiva em tempo real.
• Isole as chaves de CI/CD das permissões de publicação. O token que constrói e testa não deveria ser o mesmo que publica pacotes. Use tokens de npm granulares com escopo mínimo, prefira OIDC de curta duração em vez de segredos estáticos de longa vida, e configure trusted publishing onde o registro suportar. Um token de build roubado que não pode publicar não transforma sua biblioteca em um verme.
• Retire as chaves de wallet do ambiente de desenvolvimento. Não guarde seeds de produção nem chaves de implantação em arquivos do projeto, variáveis de ambiente do editor ou gerenciadores de segredos que a sessão do VS Code possa ler. Use uma hardware wallet ou um assinante isolado para qualquer operação com valor real, e wallets descartáveis e sem fundos para testes.
• Rotacione credenciais se tiver a menor dúvida. Se você instalou ou atualizou a Nx Console entre 11 e 19 de maio, trate todas as credenciais acessíveis a partir dessa máquina como comprometidas: tokens de npm e GitHub, chaves de nuvem e, muito especialmente, qualquer chave de wallet que tenha tocado esse equipamento. A rotação é barata comparada a assumir que nada aconteceu.

Que sinais indicam que uma extensão ou pacote está comprometido?

Nem sempre há um CVE publicado quando você precisa. O que tornou este incidente difícil de detectar, segundo as análises da Microsoft e StepSecurity, é que ele não se apoiou em infraestrutura externa desconhecida, mas em plataformas de confiança — o próprio Marketplace oficial, o GitHub, o registro do npm —, justamente onde as ferramentas de segurança costumam baixar a guarda. Por isso, a recomendação das equipes de resposta (CISA, CERT-EU) não foi buscar uma assinatura específica, mas revisar acessos e atividades incomuns sobre essa infraestrutura de confiança durante a janela de 18-19 de maio.

O indicador de ecossistema mais confiável nesta campanha foi temporal: uma rajada de versões novas publicadas quase simultaneamente em muitos pacotes do mesmo autor ou organização — o padrão de um token de publicação roubado republicando em massa, como as 300+ versões da @antv em ~22 minutos. É um padrão que as ferramentas de análise de dependências sinalizam em tempo real.

A defesa prática não é detectar o dia zero, mas reduzir o raio de explosão: atualizações manuais e revisadas em máquinas com chaves, permissões mínimas e separação rígida entre o computador onde você escreve código e o local onde vivem as chaves que movimentam dinheiro.

Quais lições ficam para o desenvolvimento Web3?

Três dados do próprio incidente concentram a lição. O primeiro é o tempo de reação: a CISA levou nove dias para emitir o alerta formal (do comprometimento de 19 de maio ao alerta de 28), e o CVE-2026-48027 não entrou no catálogo KEV até o dia 27. Quem esperou pelo aviso oficial para agir esteve exposto por mais de uma semana; a defesa não pode depender da cadência institucional.

O segundo é o alcance: o CERT-EU documentou a Comissão Europeia como vítima downstream de um comprometimento anterior do mesmo grupo na ferramenta Trivy, datado de março de 2026. Ou seja, o UNC6780 estava há pelo menos três meses operando na mesma cadeia de suprimentos antes que a indústria conectasse os pontos. A superfície de um projeto cripto não termina mais no contrato auditado: começa no editor, no registro de pacotes e no pipeline de implantação.

O terceiro é o que mais ensina, porque foi o que funcionou: segundo o GitHub, os repositórios de clientes não foram afetados precisamente porque o acesso comprometido não os alcançava — a segregação de credenciais conteve o dano. Essa é a fronteira que separa uma brecha incômoda de uma perda irreversível. As assinaturas SLSA e as atestações do npm continuam úteis, mas o TeamPCP as cooptou: elas provam que um pacote veio de um pipeline, não que esse pipeline era honesto. A defesa se desloca para as permissões mínimas e a hipótese de comprometimento por padrão — e a nunca deixar as chaves que movimentam valor ao alcance de um editor.

Fontes e links: Postmortem oficial da Nx · StepSecurity (extensão comprometida) · SecurityWeek (GitHub confirma 3.800 repos) · The Record (clientes não afetados) · OX Security (Mini Shai-Hulud) · SANS ISC (UNC6780 / Vect) · CVE-2026-48027 · Alerta CISA (28-mai) · npm (event-stream/Copay, 2018) · Ledger Connect Kit (2023) · @solana/web3.js (2024)