Um único token npm derrubou a segurança de bilhões de dólares em infraestrutura corporativa

O grupo estatal norte-coreano Sapphire Sleet comprometeu o Axios, e seu pipeline de CI/CD pode ter sido a porta de entrada.

Se você trabalha com JavaScript em ambientes corporativos, este incidente precisa entrar direto no seu backlog de segurança. O ataque ao Axios não foi sofisticado no sentido técnico, foi cirúrgico na exploração de algo que a maioria dos times simplesmente ignora: a lacuna entre o seu repositório Git e o que o npm install de fato baixa em produção.

O que aconteceu, em detalhes técnicos

O grupo Sapphire Sleet obteve um token de acesso npm de longa duração do principal mantenedor do Axios. Com isso em mãos, o ataque foi executado em duas etapas coordenadas:

Etapa 1 — envenenamento silencioso da dependência: Minutos antes de publicar as versões comprometidas do Axios, os atacantes publicaram um pacote chamado plain-crypto-js@4.2.1, uma subdependência que não existia em lugar nenhum: não estava no package.json do repositório oficial, não aparecia nas release notes, e não gerou nenhum commit suspeito no GitHub.

Etapa 2 — exploração de resolução de dependência temporal: Ao publicar as versões infectadas do Axios logo em seguida, qualquer npm install ou npm update que buscasse a nova versão automaticamente resolvia e baixava o plain-crypto-js malicioso junto. O payload era um Remote Access Trojan (RAT) multiplataforma, macOS, Windows e Linux.

O código ficou ativo no registry por aproximadamente três horas. Pouco tempo? Depende do que você considera “pouco”. Em ambientes com pipelines de CI/CD automatizados, três horas são suficientes para que milhares de builds corporativos aconteçam e distribuam o artefato infectado para produção.

Por que isso é estruturalmente diferente de um CVE comum

A maioria dos ataques a pacotes npm que você já leu envolve typosquatting (axois, axois-http) ou dependency confusion. Este não.

O vetor aqui foi a sincronização temporal entre a publicação de uma subdependência e o pacote principal, explorando o comportamento padrão dos package managers: ao resolver axios@latest, o npm não te pergunta se plain-crypto-js é legítimo, ele simplesmente o instala.

O que torna isso ainda mais perigoso:

• Nenhuma ferramenta que monitora commits no GitHub detectou nada. O payload nunca passou por code review, existia somente no registry npm.

• O Axios é uma dependência transitiva em dezenas de SDKs de terceiros. Você pode estar rodando a versão comprometida sem nem saber que usa Axios.

• Ambientes efêmeros destroem evidências. Se um container foi buildado durante aquelas três horas e já foi desativado, o invasor pode ter mantido persistência via credenciais roubadas, mas você não vai encontrar o artefato para fazer análise forense.

O ponto cego que o Sapphire Sleet explorou

GitHub (auditado, limpo)   ≠   npm registry (onde o ataque aconteceu)

A maioria dos times de segurança monitora repositórios de código. O canal de distribuição de produção é um vetor separado, e muito menos auditado. É exatamente nesse gap que o ataque viveu.

Fontes: análise técnica da Socket Security; documentação do incidente pelos mantenedores do Axios.