Pacote npm Axios comprometido: ataque à cadeia de suprimentos distribui RAT multiplataforma

Em 31 de março de 2026, duas versões maliciosas do axios, o popularíssimo cliente HTTP para JavaScript com mais de 100 milhões de downloads semanais, foram publicadas brevemente no npm por meio da conta comprometida de um mantenedor. Os pacotes continham uma dependência oculta que instalava um trojan de acesso remoto (RAT) multiplataforma em qualquer máquina que executasse npm install (ou o equivalente em outros gerenciadores de pacotes, como o Bun) durante um período de duas horas.

As versões maliciosas (1.14.1 e 0.30.4) foram removidas do npm até 03:29 UTC. Mas, enquanto estiveram disponíveis, qualquer pessoa cujo pipeline de CI/CD, ambiente de desenvolvimento ou sistema de build baixou uma instalação nova pode ter sido comprometida sem sequer tocar em uma linha de código do Axios.

Resumo

Como o ataque foi construído

Não se trata de um pacote com nome parecido criado para enganar nem de uma dependência suspeita que entrou sorrateiramente no build. O invasor tinha (ou obteve) acesso direto para publicar o pacote oficial axios no npm, provavelmente comprometendo a conta de um mantenedor. Segundo um colaborador na discussão oficial da issue no GitHub, a conta supostamente comprometida pertencia ao mantenedor @jasonsaayman, cujas permissões no repositório eram superiores às dos demais colaboradores, o que dificultou uma resposta rápida.

O invasor não modificou diretamente nenhum arquivo-fonte do Axios. Em vez disso, adicionou uma dependência maliciosa preparada com antecedência, plain-crypto-js@4.2.1, ao package.json das novas versões do axios. O pacote plain-crypto-js foi criado especificamente para esse ataque: uma versão anterior "limpa" (4.2.0) havia sido publicada 18 horas antes, provavelmente para dar ao pacote um breve histórico no registro. A versão 4.2.1 continha a carga maliciosa.

Quando um desenvolvedor ou sistema de CI executa npm install axios@1.14.1, o npm resolve a árvore de dependências, baixa plain-crypto-js@4.2.1 e executa automaticamente o hook postinstall: node setup.js. É nessa execução de script que o comprometimento começa.

O dropper: ofuscação dupla e autodestruição

O dropper setup.js, executado no postinstall, usa duas camadas de ofuscação para evitar a análise estática:

1. Codificação Base64 invertida com substituição do caractere de preenchimento

2. Cifra XOR com a chave OrDeR_7077 e um valor constante de 333

Após ser decifrado, o script detecta o sistema operacional do host por meio de os.platform() e se conecta ao servidor C2 em sfrclak[.]com:8000 (IP: 142.11.206.73) para baixar uma carga de segundo estágio adequada à plataforma.

Após a execução, o malware apaga os próprios rastros: exclui setup.js, remove o package.json que continha o hook postinstall e o substitui por um package.md limpo, renomeado para package.json. Se você inspecionar node_modules/plain-crypto-js depois, não encontrará sinais óbvios de que havia um script postinstall.

Cargas específicas para cada plataforma

As cargas de segundo estágio foram desenvolvidas especificamente para cada plataforma.

macOS

Um AppleScript baixa um binário para /Library/Caches/com.apple.act.mond, imitando intencionalmente a convenção de nomes dos processos em segundo plano da Apple para passar despercebido. Depois de instalado, o RAT:

• Gera um ID exclusivo de vítima com 16 caracteres

• Coleta informações do sistema: nome do host, nome de usuário, versão do macOS, horários de inicialização/instalação, arquitetura da CPU (mac_arm ou mac_x64) e processos em execução

• Envia sinais ao C2 a cada 60 segundos usando uma string falsa de User-Agent do IE8/Windows XP

• Aceita quatro comandos do invasor:

  • peinject: recebe do C2 um binário codificado em Base64, decodifica-o, grava-o em um arquivo temporário oculto (por exemplo, /private/tmp/.XXXXXX), faz assinatura de código ad hoc por meio de codesign --force --deep --sign - para contornar o Gatekeeper e o executa

  • runscript: executa comandos arbitrários do shell por meio de /bin/sh ou executa arquivos AppleScript com osascript

  • rundir: enumera metadados do sistema de arquivos em /Applications, ~/Library e ~/Application Support

  • kill: encerra o processo do RAT

Windows

Um downloader em VBScript copia o binário do PowerShell para %PROGRAMDATA%\wt.exe (disfarçado de Windows Terminal) e executa um RAT do PowerShell oculto, com opções para ignorar a política de execução.

Linux

Um RAT em Python é baixado para /tmp/ld.py e iniciado como um processo em segundo plano órfão por meio de nohup python3, desvinculando-o da sessão de terminal que o iniciou.

Outros pacotes comprometidos

Também foram observados dois outros pacotes distribuindo a dependência maliciosa plain-crypto-js:

• @qqbrowser/openclaw-qbot@0.0.130 — inclui um axios@1.14.1 adulterado, com a dependência injetada (SNYK-JS-QQBROWSEROPENCLAWQBOT-15850776)

• @shadanai/openclaw (versões 2026.3.31-1, 2026.3.31-2) — inclui diretamente o plain-crypto-js (SNYK-JS-SHADANAIOPENCLAW-15850775)

Esses pacotes secundários sugerem uma infraestrutura de ataque coordenada ou o uso ativo do plain-crypto-js malicioso em campanhas relacionadas.

Quem está realmente em risco

A janela de publicação de três horas (00:21 a 03:29 UTC) é o principal fator limitante. O risco é maior para:

• pipelines de CI/CD que não fixam as versões das dependências e executam npm install em horários programados ou a cada commit — especialmente os que rodam durante a noite ou no início da manhã, no horário UTC.

• Desenvolvedores que executaram npm install ou npm update durante esse período e baixaram as versões afetadas.

• Projetos que dependem de @qqbrowser/openclaw-qbot ou @shadanai/openclaw, cuja exposição não depende dessa janela.

Se seu arquivo de lock (package-lock.json ou yarn.lock) foi enviado ao repositório antes da publicação das versões maliciosas e a instalação não o atualizou, você não foi afetado. Nesse caso, os arquivos de lock são sua primeira linha de defesa.

As versões maliciosas foram removidas do registro do npm. No entanto, quem as instalou durante esse período deve presumir que o sistema foi totalmente comprometido: o RAT estava ativo, enviando sinais e pronto para executar cargas adicionais arbitrárias.

Como corrigir com a Snyk e verificar sua exposição

Se você usa a Snyk ou é cliente, qualquer uma das várias integrações da Snyk alertará sobre projetos que incluem a versão comprometida e maliciosa da dependência axios, seja por meio da Snyk CLI, da integração com o app da Snyk ou de outra forma.

O banco de dados da Snyk contém registros para SNYK-JS-AXIOS-15850650 e SNYK-JS-PLAINCRYPTOJS-15850652. Assim, snyk test sinalizará as versões afetadas e a dependência transitiva maliciosa.

Além disso, se você tem o plano Enterprise, verá um relatório Zero Day no aplicativo, como nos incidentes de segurança zero-day anteriores, por exemplo, LiteLLM, Shai-Hulud e outros. Esse relatório oferece uma visão de todo o sistema para localizar e identificar facilmente projetos e repositórios afetados que tenham a dependência vulnerável axios:

Se você ainda não usa a Snyk, há um plano gratuito. É fácil começar e auditar seu ambiente em busca de um possível comprometimento do axios ou de outros problemas de segurança:

# Install Snyk CLI if you haven't already
npm install -g snyk

# Authenticate
snyk auth

# Test your project
snyk test

Para usuários do Bun: solução alternativa com a Snyk (no momento da redação, o suporte nativo a bun.lock na Snyk CLI é limitado):

A solução alternativa recomendada é gerar, com a opção integrada -y do Bun, um arquivo de lock compatível com o yarn.lock, que a Snyk consegue analisar:

# 1. Regenerate lockfile in yarn.lock format
bun install -y

# 2. Run snyk against the generated yarn.lock
snyk test --file=yarn.lock

Se preferir, siga uma das etapas abaixo para localizar e verificar se você foi afetado pelo comprometimento do axios:

Etapa 1: verifique se há versões afetadas no arquivo de lock

# Check for axios 1.14.1 or 0.30.4
grep -E '"axios"' package-lock.json | grep -E '1\.14\.1|0\.30\.4'

# Or with yarn
grep -E 'axios@' yarn.lock | grep -E '1\.14\.1|0\.30\.4'

Etapa 2: verifique se há a dependência maliciosa

# Look for plain-crypto-js in your dependency tree
npm ls plain-crypto-js

# Or search node_modules directly
find node_modules -name "plain-crypto-js" -type d

Etapa 3: verifique se há instalações em tempo de execução do Bun com a dependência axios maliciosa

Se você usa o Bun, verifique seu bun.lock (arquivo de lock em texto, Bun v1.1+):

grep -E 'axios' bun.lock | grep -E '1\.14\.1|0\.30\.4'

Verifique também se há a dependência transitiva maliciosa:

grep 'plain-crypto-js' bun.lock

Observação: versões mais antigas do Bun geram um bun.lockb binário. Para inspecioná-lo, primeiro converta-o:

> bun bun.lockb  # prints human-readable output to stdout
> bun bun.lockb | grep -E 'axios.*1\.14\.1|axios.*0\.30\.4'
> bun bun.lockb | grep 'plain-crypto-js'

Etapa 4: procure IOCs em sistemas comprometidos

Se você acredita que uma máquina executou npm install durante o período afetado, procure estes indicadores:

Outras recomendações de correção para o gerenciador de pacotes npm

Se você não foi afetado (por precaução):

1. Fixe o axios em uma versão reconhecidamente segura no seu package.json. Qualquer versão diferente de 1.14.1 ou 0.30.4 é segura.

2. Envie seu arquivo de lock ao repositório e garanta que o CI use npm ci (e não npm install) para preservar a integridade do arquivo de lock.

3. Adicione plain-crypto-js a uma lista de bloqueio no seu gerenciador de pacotes ou ferramenta de segurança.

Considere ativar --ignore-scripts nas instalações do npm em ambientes de CI que não precisam de hooks de ciclo de vida:

npm ci --ignore-scripts

Isso impede totalmente a execução de scripts postinstall, o que teria bloqueado essa via de ataque. Atenção: isso pode interromper pacotes que realmente precisam de etapas pós-instalação, como complementos nativos.

Além disso, considere adotar o projeto de código aberto npq e disponibilizá-lo aos seus desenvolvedores. Ele adiciona verificações prévias de segurança e integridade antes da instalação de dependências.

Por fim, recomendamos consultar estas boas práticas de segurança para npm, compiladas publicamente.

Se você foi afetado (presuma que houve comprometimento):

1. Contenha imediatamente: isole todos os sistemas que executaram npm install durante o período afetado.

2. Altere todos os segredos: considere comprometidas todas as credenciais na máquina afetada — chaves de API, chaves SSH, credenciais de nuvem, tokens do npm e do GitHub. Não faça a rotação no mesmo local: revogue e emita novas credenciais.

3. Investigue movimentação lateral: verifique os logs em busca de conexões de saída para sfrclak[.]com ou 142.11.206.73. Se o RAT estava ativo, o invasor tinha capacidade de executar código arbitrário e pode ter enumerado ou exfiltrado outros dados.

4. Reconstrua os ambientes: não tente limpar sistemas comprometidos. Reconstrua-os usando um snapshot ou uma imagem-base reconhecidamente limpa.

5. Audite os pipelines de CI: revise os logs de build referentes ao período em UTC de 31 de março de 2026 para identificar quais pipelines instalaram as versões afetadas.

O panorama geral: segurança das contas de mantenedores

Este ataque segue um padrão já conhecido: comprometer a conta de um mantenedor legítimo, publicar uma versão maliciosa de um pacote confiável e se aproveitar da confiança implícita que o ecossistema deposita nos pacotes registrados. Já vimos essa estratégia ser usada contra o plugin Prettier do ESLint, contra vários pacotes pertencentes a um desenvolvedor prolífico, por meio de phishing e na campanha Shai-Hulud, que comprometeu mais de 600 pacotes.

O que torna o Axios especialmente relevante é a escala: 100 milhões de downloads semanais significam que até mesmo uma janela maliciosa de duas horas representa um enorme potencial de impacto. O invasor também demonstrou sofisticação operacional: preparou a dependência maliciosa com antecedência, usou um histórico de versões “limpo”, ofuscou o dropper duas vezes, criou RATs específicos para cada plataforma e implementou a autodestruição para apagar vestígios. Não foi algo oportunista

Para organizações que dependem de código aberto em grande escala, a lição não é parar de usar o npm nem desconfiar de todas as dependências. É entender quais controles da cadeia de suprimentos teriam detectado o ataque: exigir o uso de arquivos de lock, auditar scripts postinstall e monitorar, durante a execução, a criação inesperada de processos ou conexões de saída de ambientes de build. Vale revisitar o guia da Snyk para prevenir ataques à cadeia de suprimentos do npm e as considerações de segurança sobre arquivos de lock à luz deste incidente.

Se você quiser entender essa categoria de ataque em termos conceituais, o Snyk Learn tem uma lição específica sobre comprometimento de pacotes legítimos, que apresenta os padrões de ataque e os controles de defesa.

Linha do tempo