Em resumo
Em 30 e 31 de março de 2026, as versões 1.14.1 e 0.30.4 do axios foram comprometidas no npm com uma dependência maliciosa que instala um cavalo de Troia de acesso remoto (RAT) em máquinas infectadas. Ambas as versões foram despublicadas. A versão segura é a 1.14.0. Se você instalou axios@1.14.1 ou 0.30.4, trate a máquina como comprometida e rotacione todas as credenciais imediatamente.
O que é axios e por que isso importa
axios tem 100 milhões de downloads semanais no npm. É o cliente HTTP em inúmeros frameworks de frontend, serviços de backend Node.js e aplicações corporativas. Quando um pacote tão fundamental é comprometido, o raio de impacto é enorme — desenvolvedores que executaram npm install em uma pequena janela de tempo entre 30 e 31 de março instalaram malware em suas máquinas sem saber.
Este não é um risco hipotético de cadeia de suprimentos. Aconteceu, foi confirmado, e a carga útil (payload) era séria: um cavalo de Troia de acesso remoto em múltiplas etapas capaz de executar comandos arbitrários, exfiltrar dados do sistema e persistir em máquinas infectadas.
Se sua equipe usa axios, e você utiliza o Apidog para projetar e testar suas integrações de cliente HTTP, leia isto antes do seu próximo deploy.
Cronologia do ataque
30 de março de 2026 — 23:59:12 UTC:
Um pacote malicioso chamado plain-crypto-js@4.2.1 é publicado no npm por uma conta usando nrwise@proton.me. Uma versão anterior limpa (4.2.0) havia sido publicada 18 horas antes como um typosquat da biblioteca legítima crypto-js.
31 de março de 2026 — 00:05:41 UTC:
A detecção automatizada de malware do Socket sinaliza plain-crypto-js@4.2.1 como malicioso — seis minutos após ser publicado.
31 de março de 2026 — pouco depois da meia-noite:
axios@1.14.1 é publicado no npm, incluindo plain-crypto-js@4.2.1 como uma dependência. O lançamento não aparece nas tags oficiais do repositório axios no GitHub. A tag legítima mais recente permanece v1.14.0.
31 de março de 2026 — manhã:
A issue #10604 do GitHub é aberta publicamente, relatando que axios@1.14.1 e axios@0.30.4 foram comprometidos. Os mantenedores do Axios confirmam que inicialmente não conseguem revogar o acesso do invasor — a conta comprometida tem permissões npm superiores às dos mantenedores legítimos.
31 de março de 2026:
Ambas as versões axios@1.14.1 e axios@0.30.4 são despublicadas do npm. Os mantenedores do Axios começam a revogar tokens, apertar os controles de publicação e investigar como um token npm de longa duração foi explorado para obter acesso de publicação não autorizado.
Como o ataque funcionou
O ataque explorou uma falha no fluxo de trabalho de publicação do axios: um token npm de longa duração foi usado em conjunto com a publicação confiável. O invasor — provavelmente após comprometer as credenciais de um mantenedor — usou este token para publicar uma nova versão fora do processo de lançamento normal.
A nova versão introduziu plain-crypto-js@4.2.1 como uma dependência. O nome do pacote foi projetado para parecer um utilitário de criptografia legítimo; a versão limpa anterior 4.2.0 estabeleceu um breve histórico para reduzir a suspeita.
Dentro de plain-crypto-js@4.2.1, a análise do Socket encontrou uma carga útil multiestágio:
- Estágio 1 — Execução: O pacote executa código no momento da instalação (via scripts de ciclo de vida do npm) para instalar uma carga útil secundária.
- Estágio 2 — Implantação do RAT: A carga útil instala um cavalo de Troia de acesso remoto que abre um backdoor persistente.
- Estágio 3 — Exfiltração: O RAT é capaz de executar comandos arbitrários de shell enviados de um servidor C2, ler variáveis de ambiente e segredos do sistema de arquivos e enviar dados do sistema pela rede.
O RAT persiste após reinicializações. Ou seja, mesmo após remover o pacote npm, a máquina segue em risco até que o RAT seja explicitamente identificado e removido.
Fui afetado?
Você está potencialmente afetado se:
- Executou
npm install axiosounpm install(com axios empackage.json) entre 30 de março, 23:59 UTC e 31 de março de 2026, meio-dia UTC. - Seu
node_modules/axios/package.jsonmostra a versão1.14.1ou0.30.4. - Seu
package-lock.jsonouyarn.lockresolve o axios para1.14.1ou0.30.4.
Verifique imediatamente:
# Verificar versão instalada
npm list axios
# Checar lock file
grep '"axios"' package-lock.json | head -5
# Checar presença do plain-crypto-js
npm list plain-crypto-js
ls node_modules/plain-crypto-js 2>/dev/null && echo "INFECTADO" || echo "Não encontrado"
Se plain-crypto-js estiver presente em seu node_modules, você executou a versão maliciosa.
O que fazer agora
1. Atualize o axios imediatamente
npm install axios@1.14.0
# ou pin para a versão segura mais recente
npm install axios@latest
Verifique:
npm list axios
# Deve mostrar 1.14.0 ou superior (assim que uma 1.14.x limpa for publicada)
2. Se você instalou a versão comprometida
Não trate isso como uma atualização de dependência rotineira. Trate a máquina como comprometida:
-
Rotacione todos os segredos acessíveis dessa máquina: chaves de API, credenciais de banco de dados, chaves SSH, tokens de provedores de nuvem, variáveis
.env. - Verifique suas variáveis de ambiente — o RAT visa especificamente segredos no ambiente de processo e no sistema de arquivos.
- Audite as conexões de rede de saída do período afetado — procure por conexões para IPs desconhecidos.
- Procure por persistência — verifique tarefas cron, scripts de inicialização e serviços systemd adicionados por volta do período do comprometimento.
- Reinstale o sistema operacional da máquina se for um CI runner ou servidor de produção que teve a versão comprometida instalada. Se for um laptop de desenvolvedor, considere as credenciais comprometidas e rotacione tudo antes de considerá-lo limpo.
3. Audite seus pipelines de CI/CD
Se o pipeline de build executou npm install durante a janela de tempo, seu ambiente de CI pode ter sido comprometido. Verifique:
# Verificar logs de build do período afetado
# Procure por axios@1.14.1 em qualquer saída de instalação
# Verifique se o node_modules do CI está limpo
npm list axios plain-crypto-js
Rotacione quaisquer segredos aos quais seu pipeline de CI tenha acesso: chaves de deploy, credenciais de provedores de nuvem, tokens de registro.
4. Verifique seu arquivo de lock
Arquivos de lock (package-lock.json, yarn.lock) devem fixar versões exatas. Se o seu arquivo de lock tiver 1.14.1, regenere-o:
# Remover e regenerar
rm package-lock.json
npm install
Verifique se o novo arquivo de lock resolve o axios para uma versão segura antes de commitar.
Usando Apidog para auditar suas chamadas de API do axios
Se você usa o axios como seu cliente HTTP para fazer chamadas de API, o Apidog pode ajudá-lo a verificar se sua integração ainda está enviando as requisições corretas após a atualização da dependência.
Após atualizar para axios@1.14.0, importe seus endpoints de API existentes para o Apidog e execute uma rápida verificação de regressão para confirmar que o comportamento não mudou. Isso é especialmente útil se você estiver preocupado que a versão maliciosa possa ter adulterado as cargas úteis de requisição ou resposta — as asserções de resposta do Apidog permitem que você valide valores de campo exatos, cabeçalhos e códigos de status:
// Apidog post-response assertion
pm.test("Resposta limpa — sem campos injetados", () => {
const body = pm.response.json();
pm.expect(body).to.not.have.property('__injected');
pm.expect(pm.response.headers.get('X-Injected-Header')).to.be.null;
});
Executar sua suíte de testes completa contra a versão atualizada do axios no Apidog fornece uma linha de base limpa e documentada antes de enviar para produção.
Experimente o Apidog gratuitamente para configurar testes de regressão de cliente HTTP.
Por que ataques de cadeia de suprimentos no npm são difíceis de parar
O ataque ao axios não é uma anomalia. É um padrão:
- event-stream (2018): Um mantenedor malicioso adicionou uma carga útil visando carteiras de bitcoin. 8 milhões de downloads semanais.
- ua-parser-js (2021): Comprometido para instalar um minerador de criptomoedas e um ladrão de senhas.
- node-ipc (2022): Mantenedor adicionou intencionalmente código destrutivo visando IPs russos/bielorrussos.
- xz utils (2024): Campanha de engenharia social de dois anos para criar um backdoor em uma biblioteca de compressão central do Linux.
- axios (2026): Credenciais de mantenedor comprometidas usadas para publicar um RAT via uma dependência maliciosa.
O ponto central: confiança na conta de publicação, não no código. O modelo do npm concede acesso de publicação aos mantenedores, e se as credenciais de um mantenedor forem comprometidas, o invasor herda essa confiança.
Mitigações práticas:
| Medida | O que faz |
|---|---|
Arquivos de lock (package-lock.json) |
Fixa versões exatas, previne atualizações silenciosas |
npm audit no CI |
Sinaliza vulnerabilidades conhecidas antes do deploy |
| Socket.dev / Snyk | Análise comportamental — sinaliza pacotes suspeitos mesmo antes da existência de CVEs |
| Autenticação de dois fatores no npm | Torna o comprometimento de credenciais mais difícil |
npm publish com tokens de curta duração |
Limita a janela de exposição caso um token vaze |
| Ler arquivos de lock em PRs | Detecta alterações inesperadas de dependência na revisão de código |
A equipe do axios já reconheceu que tokens npm de longa duração estavam no centro do problema e está adotando controles de publicação mais rigorosos. Mas a solução depende do ecossistema como um todo, não só de pacotes individuais.
Indicadores de Comprometimento (IOCs)
Conforme análise do Socket:
-
Pacotes maliciosos:
plain-crypto-js@4.2.1,axios@1.14.1,axios@0.30.4 -
E-mail do publicador:
nrwise@proton.me - Comportamento: Conexões de rede no momento da instalação do npm, persistência do RAT, exfiltração de variáveis de ambiente
- Versões seguras do axios: 1.14.0 e anteriores (exceto 0.30.4), 1.13.x, 1.12.x
Se suspeitar de infecção, registre um relatório com a segurança do npm em security@npmjs.com e preserve os logs.
Conclusão
O comprometimento do axios 1.14.1 reforça que a segurança de dependências é um processo contínuo. Fixe suas versões, execute ferramentas de análise comportamental como o Socket no seu CI, rotacione credenciais diante de qualquer anomalia e mantenha seus arquivos de lock sob revisão.
Se você precisa reconstruir a confiança na integração de API após atualizar o axios, o Apidog oferece os cenários de teste, asserções e ferramentas de mocking para validar o comportamento do seu cliente HTTP antes do deploy.
FAQ
Quais versões do axios foram comprometidas?
axios@1.14.1 e axios@0.30.4. Ambas foram despublicadas do npm. A versão segura é 1.14.0 (ou qualquer versão das linhas 1.13.x, 1.12.x).
O que a carga útil maliciosa do axios faz?
Inclui plain-crypto-js@4.2.1, que implanta uma carga útil multiestágio incluindo um cavalo de Troia de acesso remoto (RAT). O RAT pode executar comandos arbitrários de um servidor C2 remoto, exfiltrar variáveis de ambiente e segredos, e persistir após reinicializações.
Como sei se instalei a versão comprometida?
Execute npm list axios — se mostrar 1.14.1 ou 0.30.4, você está afetado. Verifique também npm list plain-crypto-js — se esse pacote estiver presente, o código malicioso foi executado em sua máquina.
Basta apenas atualizar o axios?
Não. A atualização remove a dependência maliciosa daqui para frente, mas o RAT já pode estar instalado e persistindo na máquina. Se você instalou a versão comprometida, rotacione todos os segredos e audite a máquina em busca de mecanismos de persistência.
Como o invasor publicou no npm sem ser um mantenedor?
O invasor provavelmente comprometeu as credenciais de um mantenedor e explorou um token npm de longa duração que tinha acesso de publicação. A equipe do axios está investigando e apertando os controles de publicação.
Qual a diferença entre isso e uma vulnerabilidade comum?
Uma vulnerabilidade é uma falha em um código legítimo. Um ataque à cadeia de suprimentos introduz código malicioso através de um canal de publicação confiável. O código comprometido nunca esteve no repositório GitHub do axios — ele foi injetado diretamente na publicação do npm.
Como posso proteger meus projetos de futuros ataques à cadeia de suprimentos?
Use arquivos de lock, execute npm audit no CI, adicione uma ferramenta como Socket.dev para análise comportamental, habilite 2FA em contas npm, use tokens de publicação de curta duração e audite as diferenças de seus arquivos de lock na revisão de código.
Top comments (0)