Blog

Ataque à cadeia de suprimentos axios@1.14.1: O que fazer agora

Ashley Innocent

Ashley Innocent

2 abril 2026

Ataque à cadeia de suprimentos axios@1.14.1: O que fazer agora

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.

button

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 convincente 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 que havia sido 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 (payload) multiestágio:

  1. 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.
  2. Estágio 2 — Implantação do RAT: A carga útil instala um cavalo de Troia de acesso remoto que abre um backdoor persistente.
  3. 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, o que significa que as máquinas que instalaram a versão comprometida permanecem em risco mesmo após a remoção do pacote npm, a menos que o RAT seja explicitamente caçado e removido.

Fui afetado?

Você está potencialmente afetado se:

Verifique imediatamente:

# Check installed version
npm list axios

# Check lock file
grep '"axios"' package-lock.json | head -5

# Check for plain-crypto-js presence
npm list plain-crypto-js
ls node_modules/plain-crypto-js 2>/dev/null && echo "INFECTED" || echo "Not found"

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
# or pin to latest safe
npm install axios@latest

Verifique:

npm list axios
# Should show 1.14.0 or higher (once a clean 1.14.x is published)

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:

3. Audite seus pipelines de CI/CD

Se o seu pipeline de build executou npm install durante a janela de tempo, seu ambiente de CI pode ter sido comprometido. Verifique:

# Check build logs for the affected timeframe
# Look for axios@1.14.1 in any install output

# Verify current CI node_modules are clean
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:

# Remove and regenerate
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("Response is clean — no injected fields", () => {
    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 você 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:

O fio condutor comum: 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 que realmente ajudam:

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 reconheceu desde então que tokens npm de longa duração faziam parte do problema e está se movendo para controles de publicação mais rigorosos. Mas a solução precisa vir do ecossistema, não apenas de pacotes individuais.

Indicadores de Comprometimento (IOCs)

De acordo com a análise do Socket:

Se você 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 é um lembrete de que a segurança de dependências não é uma auditoria única — é um processo contínuo. Fixe suas versões, execute ferramentas de análise comportamental como o Socket em seu CI, rotacione credenciais quando algo parecer errado e mantenha seus arquivos de lock sob revisão na revisão de código.

Se você precisa reconstruir a confiança em sua integração de API após atualizar o axios, o Apidog oferece os cenários de teste, asserções e ferramentas de mocking para verificar o comportamento do seu cliente HTTP antes de você lançar.

button

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?Ele 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.

Pratique o design de API no Apidog

Descubra uma forma mais fácil de construir e usar APIs

Cadastre-se gratuitamenteBaixar