Aconteceu de novo. E dessa vez foi grande.

Se você é desenvolvedor JavaScript — e estatisticamente, se está lendo isso, provavelmente é — existe uma chance real de que nas últimas 24 horas seu npm install tenha baixado um trojan de acesso remoto completo. Sem você alterar uma linha de código. Sem clicar em nenhum link suspeito. Sem fazer absolutamente nada de errado.

O Axios, aquela biblioteca HTTP que está em literalmente 80% dos ambientes JavaScript em produção, foi comprometido no npm. Versões maliciosas foram publicadas, rodaram por algumas horas, e nesse intervalo qualquer pipeline de CI/CD, ambiente de desenvolvimento ou build system que fez um npm install fresco pode ter sido infectado.

Eu já vi ataques de supply chain antes — event-stream em 2018, ua-parser-js em 2021, o fiasco do colors.js, o comprometimento do LiteLLM. Mas o Axios? Com 83 milhões de downloads por semana? Isso é outro nível.

O que aconteceu exatamente

Na madrugada de 31 de março de 2026 (sim, hoje), alguém conseguiu acesso à conta npm do principal mantenedor do Axios, o jasonsaayman. O atacante trocou o email associado à conta para um endereço ProtonMail descartável — ifstap@proton.me — e usou o acesso para publicar duas versões envenenadas diretamente via CLI do npm:

• axios@1.14.1 (branch principal)
• axios@0.30.4 (branch legacy)

As duas branches foram envenenadas num intervalo de 39 minutos entre si. Isso não foi improviso — foi uma operação coordenada.

O detalhe mais perturbador? Se você pegar o diff binário entre o axios@1.14.0 (limpo) e o 1.14.1 (malicioso), de todos os 86 arquivos do pacote, exatamente um mudou: o package.json. Todos os outros são idênticos bit a bit. Zero linhas de código malicioso dentro do Axios propriamente dito.

A dependência fantasma

O que mudou no package.json foi a adição de uma dependência chamada plain-crypto-js@4.2.1. Esse pacote nunca é importado em lugar nenhum do código-fonte do Axios. Ele não faz nada para o Axios funcionar. Sua única razão de existir é executar um postinstall script — aquele gancho que o npm roda automaticamente depois de instalar um pacote.

E aqui começa o show de horrores.

O plain-crypto-js não apareceu do nada. A versão limpa (4.2.0) foi publicada 18 horas antes do ataque. Parece inocente, não faz nada de especial. Aí, na véspera do ataque, a versão 4.2.1 foi publicada com o payload real. Os três payloads para três sistemas operacionais diferentes já estavam prontos e esperando no servidor de comando e controle.

Planejamento. Paciência. Execução cirúrgica.

Dois segundos para comprometer sua máquina

Quando você roda npm install num projeto que depende do Axios com range semver ^1.14.0, o npm resolve para a versão mais recente — que naquele momento era a 1.14.1. O pacote baixa, e como parte da instalação, o npm executa o postinstall do plain-crypto-js.

O script setup.js usa duas camadas de ofuscação: Base64 reverso com substituição de caracteres de padding, e cifra XOR com a chave OrDeR_7077 e uma constante 333. Desobfuscado, o script detecta o sistema operacional via os.platform() e faz uma requisição para o servidor C2 em sfrclak.com:8000 (IP: 142.11.206.73).

Em dois segundos — antes mesmo do npm terminar de resolver as outras dependências — o malware já estava ligando para casa.

E aí vem a parte que realmente me preocupa: o payload é diferente para cada sistema operacional.

Payloads por plataforma

macOS

O dropper baixa um binário RAT completo escrito em C++ e o salva em:

/Library/Caches/com.apple.act.mond

Repare no path. com.apple.act.mond parece nome de processo legítimo da Apple. É uma escolha deliberada para passar despercebido em inspeções rápidas do sistema. Na execução, o RAT:

1. Gera um ID de vítima único de 16 caracteres
2. Fingerprinta o sistema (hostname, usuário, versão do macOS, timezone, tipo de CPU)
3. Faz beacon para o C2 via HTTP POST a cada 60 segundos
4. Aceita comandos remotos: executar shell, enumerar filesystem, rodar payloads adicionais, se auto-destruir

Windows

No Windows, a abordagem é diferente. O malware copia o PowerShell para %PROGRAMDATA%\wt.exe — de novo, um nome que parece legítimo (Windows Terminal usa wt.exe) — e executa um script PowerShell oculto que estabelece persistência e comunicação com o mesmo C2.

Linux

No Linux, o approach é mais direto: baixa um script Python para /tmp/ld.py e executa. Mesmo servidor, mesmo protocolo, mesmas capacidades.

O fantasma se apaga

Aqui está o toque de mestre: depois de executar o payload, o malware se autodestrói. O plain-crypto-js deleta seus próprios scripts maliciosos e substitui seu package.json por uma versão limpa.

Se você for investigar sua pasta node_modules/plain-crypto-js depois, vai encontrar um pacote aparentemente inocente. Nenhum rastro óbvio. Nenhum arquivo suspeito. Forense tradicional de “olhar os arquivos” não vai pegar nada.

Quem projetou isso não é amador.

A timeline do ataque

A cronologia revela o nível de premeditação:

A janela de exposição foi de aproximadamente 3 horas. Parece pouco, mas pense em quantos pipelines de CI/CD rodam npm install por hora no mundo inteiro. Dados da Wiz indicam que a execução do malware foi observada em 3% dos ambientes afetados — e estamos falando de uma base de 83 milhões de downloads semanais.

Por que o Axios é tão perigoso como alvo

Para ter uma perspectiva da escala: o ataque ao ua-parser-js em 2021 afetou um pacote com ~7 milhões de downloads semanais e já foi considerado um dos maiores incidentes de supply chain da história do npm. O Axios tem quase 12 vezes mais downloads.

Mais de 2 milhões de pacotes dependem do Axios direta ou indiretamente. Ele está presente em projetos React, Vue, Angular, Node.js backends, ferramentas CLI, scripts de automação. Se seu projeto JavaScript faz requisições HTTP, tem uma chance enorme de usar Axios.

E tem outro agravante que ninguém está falando o suficiente: agentes de IA. Quantos coding agents, copilots e ferramentas automatizadas rodam npm install sem revisão humana? Sem olhar o lockfile? Sem verificar o que mudou nas dependências? A superfície de ataque está crescendo mais rápido do que o ecossistema consegue se defender. E com as recentes polêmicas sobre o GitHub usando código para treinar IA, a confiança no ecossistema JavaScript está em seu ponto mais baixo.

O histórico que deveria ter nos preparado

O Axios não é o primeiro. Nem será o último. Veja o padrão:

event-stream (2018): Um atacante fez engenharia social no mantenedor para obter controle do pacote. Inseriu código que roubava criptomoedas de carteiras Copay. Foi o ataque que “escreveu o playbook” para supply chain no npm.

ua-parser-js (2021): Conta do mantenedor comprometida. Três versões maliciosas publicadas com cryptominers e um DLL que roubava credenciais de mais de 100 aplicações Windows. 7 milhões de downloads semanais afetados.

colors.js / faker.js (2022): O próprio mantenedor sabotou intencionalmente seus pacotes em protesto. Loops infinitos quebraram milhares de projetos downstream. Diferente em motivação, mas ilustra o mesmo ponto: dependência de uma única pessoa.

chalk & debug (setembro 2025): 2 bilhões de downloads combinados comprometidos com um crypto clipper que mirava especificamente carteiras Web3.

Shai-Hulud worm (setembro 2025): Mais de 500 pacotes npm infectados com um worm auto-propagante. Resultou numa advisory da CISA.

Trivy (março 2026): Duas semanas atrás. O scanner de vulnerabilidades mais usado do mundo foi comprometido, plantando backdoors persistentes em máquinas de desenvolvedores.

E agora o Axios. O padrão é sempre o mesmo: credenciais de mantenedor comprometidas, uma mudança minúscula no postinstall, payload que se autodestrói. A diferença é que cada novo ataque tem escala maior e sofisticação crescente.

Você foi afetado? Como verificar

Antes de entrar em pânico, vamos ser práticos. Rode esses comandos no seu projeto:

# Verifica se alguma das versões maliciosas está instalada
npm ls axios | grep -E "1\.14\.1|0\.30\.4"

# Verifica se o pacote fantasma existe
ls node_modules/plain-crypto-js 2>/dev/null && echo "⚠️ ENCONTRADO" || echo "✅ Limpo"

# Verifica o lockfile (se existir)
grep "plain-crypto-js" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

Se encontrou a versão maliciosa:

1. Faça downgrade imediato: npm install axios@1.14.0 (ou 0.30.3 para o branch legacy)
2. Delete o pacote fantasma: rm -rf node_modules/plain-crypto-js
3. Procure os artefatos do RAT:

# macOS
ls -la /Library/Caches/com.apple.act.mond

# Windows (PowerShell)
Test-Path "$env:PROGRAMDATA\wt.exe"

# Linux
ls -la /tmp/ld.py

4. Rotacione TODAS as credenciais da máquina afetada. Tokens de API, chaves SSH, cookies de sessão, tokens npm. Tudo.
5. Bloqueie os indicadores de comprometimento no firewall:
   • Domínio: sfrclak.com
   • IP: 142.11.206.73
   • Porta: 8000
   • Path: /6202033

Se seu lockfile estava commitado antes do ataque:

Se seu package-lock.json ou yarn.lock já existia no repositório antes de 31 de março e você usou npm ci (que respeita o lockfile), você provavelmente não foi afetado. O lockfile trava as versões exatas e não atualiza automaticamente.

A palavra-chave é “provavelmente”. Audite mesmo assim.

Como se proteger de verdade

A real é que npm install por padrão é um convite aberto para execução de código arbitrário na sua máquina. Aqui estão as medidas que realmente funcionam:

1. Desabilite postinstall scripts por padrão

# No seu .npmrc (global ou por projeto)
echo "ignore-scripts=true" >> .npmrc

Isso teria impedido completamente esse ataque. O payload não teria executado. Ponto. Alguns pacotes legítimos precisam de postinstall (esbuild, sharp), então use allowlists:

# pnpm - allowlist de scripts
# pnpm-workspace.yaml
pnpm:
  allowedScripts:
    - esbuild
    - sharp

2. Use npm ci, nunca npm install no CI/CD

# Errado - atualiza lockfile, pode puxar versões novas
npm install

# Certo - respeita lockfile, falha se houver divergência
npm ci --ignore-scripts

3. Pine versões exatas

# No .npmrc
save-exact=true

Com isso, quando você instala uma dependência, o package.json grava "axios": "1.14.0" em vez de "axios": "^1.14.0". Sem caret, sem range, sem surpresas.

4. Revise diffs de lockfile em PRs

Tratar mudanças no lockfile como mudanças de código. Qualquer nova dependência transitiva, qualquer versão bump inesperado, deve passar por revisão humana. Ferramentas como o Socket.dev fazem isso automaticamente.

5. Use pnpm ou bun

Ambos não executam lifecycle scripts por padrão. O pnpm especialmente tem um modelo de segurança mais restrito, com node_modules usando links simbólicos que previnem phantom dependencies.

6. Espere antes de atualizar

Uma prática simples que salva: não instale versões publicadas há menos de 72 horas. A maioria dos ataques é detectada e removida em horas. Um delay de dias teria impedido qualquer exposição nesse caso.

O problema real que ninguém quer resolver

Esse ataque não é um bug no código do Axios. Não existe CVE aplicável aqui. Não é uma vulnerabilidade de software que pode ser patcheada. É uma falha sistêmica na fronteira de confiança entre as credenciais de um mantenedor e o pipeline de publicação do registro.

O npm melhorou bastante desde 2021. Em dezembro de 2025, tokens legados foram finalmente eliminados. Granular Access Tokens e 2FA mais rigoroso viraram padrão. Mas claramente não foi suficiente. O atacante ainda conseguiu um token válido e publicou versões maliciosas de um dos pacotes mais baixados do mundo.

Algumas perguntas que precisamos responder como comunidade:

• Por que um único token de acesso permite publicar versões de um pacote com 83 milhões de downloads semanais sem nenhuma verificação adicional?
• Por que o npm ainda executa postinstall scripts por padrão em 2026?
• Por que não existe um mecanismo nativo de “cooling period” para novas versões de pacotes populares?
• Quantos projetos estão rodando npm install automaticamente em agentes de IA sem nenhuma auditoria?

O ecossistema JavaScript construiu um castelo de cartas de dependências onde cada carta confia cegamente na de baixo. Eventos como esse mostram que essa confiança não é merecida. Nunca foi.

O que fazer agora

Se você gerencia projetos JavaScript em produção, aqui está seu checklist para hoje:

# 1. Audite seus projetos
npm ls axios

# 2. Verifique que você está na versão segura
# 1.14.0 ou 0.30.3 (não .1 ou .4)

# 3. Adicione ignore-scripts ao .npmrc
echo "ignore-scripts=true" >> .npmrc

# 4. Configure save-exact
echo "save-exact=true" >> .npmrc

# 5. No CI/CD, use npm ci
# npm ci --ignore-scripts

# 6. Bloqueie os IOCs no firewall
# sfrclak.com / 142.11.206.73:8000

E se você encontrar evidências de comprometimento, trate como um incidente de segurança completo. Não é paranoia — é o mínimo razoável quando um RAT com capacidade de execução remota de comandos pode ter rodado na sua máquina.

A detecção da Socket.dev em 6 minutos foi impressionante. A remoção pelo npm em 3 horas foi rápida. Mas 3 horas com 83 milhões de downloads por semana é muito tempo. E da próxima vez — porque vai ter próxima vez — pode demorar mais.

Fonte de inspiração: StepSecurity — Axios Compromised on npm. Análise adicional baseada em relatórios da Socket.dev, The Hacker News e Snyk.

👉 Leia também: 97 Milhões de Downloads: Como o LiteLLM Foi Comprometido

• A IA Escapou da Caixa: Os Piores Bugs, Vazamentos e Falhas de Segurança Causados por Inteligência Artificial