A popular biblioteca Axios, utilizada em inúmeros projetos JavaScript para realizar requisições HTTP, registrou um ataque de supply chain que comprometeu duas versões específicas publicadas no registro NPM. Investigadores da StepSecurity identificaram as versões 1.14.1 e 0.30.4 como maliciosas, publicadas na madrugada de 31 de março de 2026. Os pacotes injetaram uma dependência falsa que executa um script de instalação capaz de instalar um trojan de acesso remoto em máquinas de desenvolvedores.
O incidente expôs o vasto ecossistema de desenvolvimento que depende da biblioteca, uma das mais baixadas da plataforma com mais de 100 milhões de downloads semanais. Os atacantes não alteraram o código principal do Axios, mas adicionaram uma dependência oculta chamada plain-crypto-js@4.2.1. Essa dependência ativava automaticamente ao executar npm install, instalando payloads específicos para Windows, macOS e Linux.
Como ocorreu o comprometimento da conta de manutenção
Os responsáveis pelo ataque obtiveram acesso à conta NPM do principal mantenedor do projeto, identificada como jasonsaayman. Eles alteraram o endereço de e-mail associado para ifstap@proton.me e publicaram manualmente as versões comprometidas, contornando os fluxos automatizados de integração contínua do repositório no GitHub. A primeira versão maliciosa, axios@1.14.1, foi lançada por volta das 00:21 UTC, seguida pela axios@0.30.4 aproximadamente 39 minutos depois.
Essa abordagem permitiu que os pacotes fossem disponibilizados sem acionar verificações de assinatura ou processos de CI/CD habituais. Os mantenedores do Axios reagiram rapidamente após a descoberta, e o NPM removeu ambas as versões em poucas horas, limitando o tempo de exposição a cerca de duas a três horas.
Detalhes técnicos do malware injetado
A dependência falsa plain-crypto-js@4.2.1 não era importada em nenhum ponto do código original do Axios, servindo exclusivamente para executar um script postinstall. O script atuava como um dropper de trojan de acesso remoto, estabelecendo contato com um servidor de comando e controle para baixar payloads adicionais adaptados a cada sistema operacional.
Técnicas de ofuscação foram empregadas para dificultar a análise imediata, com comandos decodificados em tempo de execução. Após a instalação bem-sucedida, o malware removia seus próprios vestígios, substituindo o arquivo package.json por uma versão limpa para evitar detecção em inspeções posteriores da pasta node_modules.
- Verificação de versões afetadas com o comando npm list axios filtrando 1.14.1 ou 0.30.4
- Checagem da presença da pasta node_modules/plain-crypto-js como indicador de comprometimento
- Busca por artefatos como arquivos temporários em /tmp/ld.py ou equivalentes em outros sistemas
Medidas de mitigação recomendadas aos desenvolvedores
Os programadores que instalaram as versões 1.14.1 ou 0.30.4 devem considerar o ambiente comprometido e agir imediatamente. A recomendação principal consiste em reverter para as versões seguras anteriores: axios@1.14.0 na ramificação mais recente ou axios@0.30.3 na versão legada.
É essencial remover a dependência falsa, executar uma instalação limpa com a flag –ignore-scripts e rotacionar todas as credenciais sensíveis, incluindo tokens NPM, chaves SSH, acessos a serviços de nuvem e variáveis de ambiente. Em pipelines de integração contínua, a adoção permanente do parâmetro que ignora scripts pós-instalação ajuda a prevenir execuções automáticas indesejadas.
Impacto no ecossistema de desenvolvimento JavaScript
O Axios figura entre as bibliotecas mais utilizadas no ecossistema Node.js e em aplicações front-end, sendo dependência direta ou indireta de inúmeros projetos corporativos e open source. O ataque destaca a vulnerabilidade inerente a contas de mantenedores individuais em pacotes de alta popularidade, mesmo quando o código principal permanece intacto.
Especialistas em segurança observam que o método empregado demonstra sofisticação operacional, com preparação prévia da dependência falsa em uma versão limpa antes da injeção do payload malicioso. Essa estratégia complicou detecções automáticas iniciais e ampliou o risco durante o curto período em que as versões ficaram disponíveis.
Orientações para verificação e limpeza de ambientes afetados
Equipes de desenvolvimento precisam auditar logs de instalação e histórico de pacotes para identificar se as versões maliciosas foram baixadas. A presença da pasta plain-crypto-js em node_modules serve como forte indicador de que o dropper foi executado, independentemente da remoção posterior de arquivos.
Após a limpeza, recomenda-se varredura completa dos sistemas com ferramentas de detecção de ameaças e monitoramento de conexões de rede para endereços associados ao servidor de controle. A atualização imediata das políticas de segurança em repositórios privados também contribui para reduzir riscos semelhantes em outros pacotes.
Prevenção de ataques futuros em registros de pacotes
O incidente reforça a importância de medidas como autenticação multifator rigorosa em contas de publicação, monitoramento contínuo de mudanças em metadados de pacotes e adoção de verificações de integridade mais robustas. Projetos de código aberto com grande adoção podem considerar processos adicionais de revisão antes de novas releases.
Desenvolvedores individuais e empresas devem priorizar o pinning de versões conhecidas como seguras em arquivos de configuração de projetos, evitando a instalação automática de atualizações sem validação prévia. Essas práticas ajudam a limitar a superfície de ataque em cadeias de suprimentos de software.
A comunidade de segurança continua acompanhando o caso para mapear possíveis vítimas e refinar ferramentas de detecção. Até o momento, não há relatos públicos de exploração em larga escala, mas a recomendação unânime é tratar qualquer instalação das versões afetadas como comprometimento total do sistema envolvido.