Se seu projeto usa axios — e se trabalha com JavaScript, provavelmente usa — isto o afeta diretamente.
Na madrugada de 31 de março (UTC), um atacante comprometeu a conta npm do mantenedor principal do axios, publicou duas versões envenenadas da biblioteca e as removeu antes que a maioria dos times na América chegasse ao escritório. A janela de exposição foi de aproximadamente três horas. Axios tem mais de 100 milhões de downloads semanais. A escala do risco potencial é difícil de subestimar.
O Que Exatamente Aconteceu
O atacante não modificou o código-fonte do axios. Em vez disso, comprometeu a conta npm de jasonsaayman, o mantenedor principal, alterou o email registrado por um endereço ProtonMail para bloqueá-lo e publicou dois releases manualmente via CLI — pulando completamente o pipeline de CI/CD do GitHub Actions do projeto.
A dependência maliciosa foi preparada com 18 horas de antecedência. Três payloads separados foram pré-construídos para três sistemas operacionais. Ambas as branches de release foram afetadas em um intervalo de 39 minutos.
As versões comprometidas são axios@1.14.1 e axios@0.30.4. Ambas injetam uma nova dependência: plain-crypto-js@4.2.1, um pacote que nunca existiu antes de 30 de março e que não é importado em nenhum lugar do código real do axios. Seu único propósito é executar um script postinstall que atua como dropper de um RAT multiplataforma, direcionado para macOS, Windows e Linux.
O Mecanismo: Por Que postinstall É Tão Perigoso
Quando executa npm install, o npm executa automaticamente os scripts definidos em package.json de cada dependência — incluindo as transitivas. Você não precisa importar plain-crypto-js no seu código. Não precisa saber que existe. Basta estar na árvore de dependências para que seu script seja executado com os privilégios da sua sessão, na sua máquina ou no seu runner de CI/CD.
StepSecurity confirmou a operação do malware via análise em runtime usando sua ferramenta Harden-Runner: uma conexão ao domínio C2 foi detectada apenas 1,1 segundos após executar npm install.
O dropper então se auto-elimina — apaga setup.js e substitui o package.json por uma versão limpa. Se inspecionar node_modules/plain-crypto-js após a instalação, verá um pacote completamente inócuo. Mas a presença dessa pasta é evidência suficiente de que o dropper foi executado.
O Que o RAT Faz
Os payloads de segunda etapa funcionam como RATs leves que fazem beacon ao servidor C2 a cada 60 segundos, transmitindo inventário do sistema e aguardando comandos. As três variantes implementam capacidades similares: execução de shell remoto, injeção de binários, navegação de diretórios, listagem de processos e reconhecimento do sistema.
No Windows, o RAT estabelece persistência via uma chave Run no registro. No Linux — e isso é revelador — não estabelece persistência: os pesquisadores da Huntress interpretam isso como evidência de que o atacante entende que os targets Linux são principalmente runners de CI/CD e contêineres, onde a persistência não é necessária porque o valor está nos segredos acessíveis durante o build.
O Google Threat Intelligence Group (GTIG) atribuiu o ataque a um ator norte-coreano rastreado como UNC1069, apontando que os hackers norte-coreanos têm experiência profunda em ataques à cadeia de suprimentos, que historicamente usaram para roubar criptomoedas.
Como Saber Se Foi Afetado
Revise seu lockfile:
# package-lock.json
grep -E '"axios"' package-lock.json | grep -E '1\.14\.1|0\.30\.4'
# yarn.lock
grep -E 'axios@' yarn.lock | grep -E '1\.14\.1|0\.30\.4'
# Procure pela dependência maliciosa diretamente
npm ls plain-crypto-js
find node_modules -name "plain-crypto-js" -type d
Procure por artefatos do RAT no sistema:
- macOS:
/Library/Caches/com.apple.act.mond - Windows:
%PROGRAMDATA%\wt.exe - Linux:
/tmp/ld.py
Se seu lockfile foi commitado antes de as versões maliciosas serem publicadas e sua instalação não o atualizou, você não foi afetado.
O Que Fazer Se Estiver Comprometido
Se artefatos do RAT forem encontrados: trate o sistema como completamente comprometido. Não tente limpar no lugar — reconstrua a partir de um estado conhecido como seguro.
Rotacione todos os segredos acessíveis a partir do sistema afetado: tokens npm, chaves SSH, credenciais cloud (AWS, GCP, Azure), API keys e qualquer valor em arquivos .env acessíveis no momento da instalação. Audite seus pipelines de CI/CD para identificar quais runs instalaram as versões afetadas — a exposição não se limita a máquinas de desenvolvimento.
Para mitigação geral: faça downgrade para axios@1.14.0 ou axios@0.30.3, remova node_modules/plain-crypto-js e reinstale com npm install --ignore-scripts.
Este incidente segue um padrão que vem se acelerando em 2026: contas de mantenedores comprometidas para publicar versões envenenadas de pacotes de alta confiança. Não é o primeiro e não será o último. A pergunta não é se seu ecossistema de dependências é um vetor de ataque viável — claramente é. A pergunta é quais controles tem em lugar para detectá-lo quando ocorrer.
Fontes: StepSecurity · Snyk · Wiz · Huntress · Socket · Help Net Security