O Axios ficou fora de controle por três horas, e os 100 milhões de downloads semanais nem perceberam

Principais conclusões

• As versões maliciosas do axios ficaram ativas por apenas cerca de três horas; portanto, as instalações realizadas antes da detecção não receberam proteção das defesas baseadas em alertas.
• O número de downloads mede a adoção, não a análise, e os axios podem ser obtidos por meio de pacotes que a equipe nunca escolheu.
• Várias medidas de controle poderiam ter interrompido essa cadeia, desde instalações bloqueadas e scripts de instalação bloqueados até janelas de quarentena, verificações de proveniência e triagem do Registro.
• Os controles preventivos mais eficazes ocorrem no momento da instalação ou antes dela, que é justamente onde muitas equipes têm investido menos.

Duas versões maliciosas do axios foram colocadas no ar em 31 de março de 2026 e permaneceram disponíveis por cerca de três horas antes que alguém as retirasse. Nesse intervalo, elas se infiltraram discretamente nas árvores de dependências de uma grande parte do ecossistema JavaScript, e quase ninguém que as instalou tinha como saber.

Ninguém do projeto os publicou. As versões foram lançadas a partir de uma conta de mantenedor invadida, publicadas manualmente com um token de longa duração roubado que contornou o próprio pipeline de CI do projeto; por isso, no registro, elas pareciam versões comuns do axios. Os números de versão pareciam normais. npm audit não apresentou nenhum resultado para o primeiro período da janela, pois o comunicado que acabaria por descrever o incidente ainda não havia sido redigido.

Três horas no meio de um ataque à cadeia de suprimentos do npm

Três horas não é muito tempo. Não é tempo suficiente para que a maioria das equipes perceba que uma nova versão foi lançada, muito menos para avaliá-la.

O padrão geral de um comprometimento no lado da publicação está bem documentado, e o axios seguiu esse padrão com uma camada adicional que não está presente na versão genérica. Ambas as versões incorporaram uma dependência totalmente nova chamada plain-crypto-js, que existia com o único propósito de executar uma carga maliciosa a partir de um gancho pós-instalação. Uma versão isca limpa desse pacote havia sido publicada cerca de 18 horas antes, o que fez com que a versão maliciosa subsequente parecesse menos como algo totalmente novo, e os próprios arquivos-fonte do axios nunca foram alterados. A engenharia social levou o invasor à máquina do mantenedor primeiro, e os direitos de publicação vieram junto com isso.

A fase interessante é a propagação. Entre a publicação e a descoberta, o caminho padrão de instalação do npm nunca exige que um pacote comprove que o artefato recebido foi compilado a partir do código-fonte e do fluxo de trabalho que ele alega ter. Essa lacuna constitui toda a janela de ataque.

A Wiz observou que o malware chegou a ser executado em cerca de 3% dos ambientes afetados que apareceram em sua telemetria, e os pesquisadores estimaram separadamente a janela de exposição em cerca de 600 mil downloads. Os dois números provêm de populações diferentes; portanto, multiplicá-los não resulta em um número real de casos. Analisados em conjunto, porém, eles descrevem a execução confirmada da carga maliciosa dentro de uma janela de exposição muito curta, e não apenas arquivos armazenados no disco.

Análise da realidade: Retirar do ar uma versão maliciosa impede novas instalações. Isso não tem efeito sobre máquinas que já a executaram, tokens que já foram exfiltrados ou imagens de contêiner já compiladas e enviadas com o código malicioso incorporado.

Por que 100 milhões de downloads semanais não são um sinal de segurança

A suposição tácita por trás da escolha de dependências populares é que popularidade significa maior escrutínio. Muitos olhos, bugs superficiais — toda essa linha de raciocínio.

É um argumento válido em relação ao código-fonte. No entanto, ele não se sustenta quando se trata da integridade da publicação, pois o foco está no repositório, enquanto o ataque ocorre no registro. Trata-se de dois artefatos distintos, e o npm não exige que eles sejam idênticos. Vários scanners estavam em operação naquela noite e muitos deles sinalizaram o problema na versão em questão em questão de minutos. Nada no caminho de instalação padrão fica à espera deles.

Há um segundo problema, e é ele que torna tão incômodo lidar com esse tipo de incidente. Algumas equipes nunca instalaram o axios diretamente. Elas instalaram algo que, por sua vez, instalou outra coisa que, por sua vez, instalou o axios.

Uma pesquisada Endor Labs citada no Top 10 da OWASP para software de código aberto estima que a proporção de vulnerabilidades presentes em dependências indiretas em cerca de 95% , em vez de nos pacotes que uma equipe escolheu propositalmente. Esse número leva em conta vulnerabilidades conhecidas, e não malware, mas mostra quanta parte de um gráfico de dependências fica fora dos pacotes que os desenvolvedores escolhem propositalmente — e esses gráficos não ficaram nem um pouco mais simples. Quando o pacote comprometido fica quatro camadas abaixo em um gráfico que ninguém realmente leu, a pergunta “Nós sequer usamos o axios?” se torna surpreendentemente difícil de responder rapidamente.

npm ls axios –all

npm ls plain-crypto-js –all

Execute esses comandos em todos os repositórios, não apenas naqueles em que você se lembra de ter adicionado um cliente HTTP. Se algum deles retornar axios 1.14.1 ou 0.30.4, ou plain-crypto-js 4.2.1, considere o host comprometido e volte a usar o axios 1.14.0 ou 0.30.3 e atualize todas as credenciais que esse host possa acessar.

O que um agente estatal queria com um cliente HTTP?

O Grupo de Inteligência contra Ameaças do Google atribuiu o ataque à Axios ao UNC1069, um agente ligado à Coreia do Norte com motivação financeira e histórico de roubos a corretoras de criptomoedas. A Microsoft rastreia atividades sobrepostas sob o nome de Sapphire Sleet, enquanto outros pesquisadores associam atividades relacionadas a nomes como BlueNoroff e Stardust Chollima. Um cliente HTTP parece um alvo estranho para um grupo dessa área, até você pensar no que se ganha ao comprometer um deles.

Máquinas de desenvolvedores e agentes de compilação, em grande escala — e esses equipamentos contêm credenciais de funções na nuvem, tokens de registro, chaves de assinatura e código-fonte de itens que ainda não foram lançados. Focar nas ferramentas de desenvolvedores em vez de diretamente na produção é um padrão que também se repete em campanhas anteriores do npm, e funciona porque as estações de trabalho dos desenvolvedores e os agentes de compilação contêm credenciais com acesso a sistemas posteriores excepcionalmente amplo.

Relatório de Investigações sobre Vazamentos de Dados de 2026 da Verizon revelou que a exploração de vulnerabilidades ultrapassou o roubo de credenciais como o principal vetor de acesso inicial, sendo responsável por 31% das violações, em comparação com 13% para o uso indevido de credenciais. No entanto, as credenciais não deixaram de ser importantes. Elas continuam sendo um dos elementos mais comuns uma vez que a invasão já está em andamento, e um ataque que extrai tokens de milhares de ambientes de compilação é exatamente o tipo de coisa que mantém esse estoque sempre reabastecido.

Shai-Hulud e a transição para o malware que se propaga automaticamente

O Axios foi um único ataque. As campanhas de worms são algo totalmente diferente.

O Shai-Hulud estabeleceu o padrão em setembro de 2025 com um código malicioso que, uma vez em execução em um ambiente de desenvolvimento ou de integração contínua (CI), procura por segredos, identifica tokens de publicação do npm e os utiliza para se inserir em mais pacotes. Uma campanha relacionada, conhecida como Mini Shai-Hulud , teve início em 29 de abril de 2026 e se estendeu por mais duas ondas em maio. No meio do caminho, a TeamPCP publicou o código-fonte do worm no GitHub — e esse não é o tipo de gênio que volta para dentro da garrafa.

A mecânica é mais importante do que a marca. Uma campanha que se propaga sozinha transforma cada vítima com direitos de publicação válidos em mais um ponto de distribuição; assim, o número de pacotes afetados continua crescendo sem que o invasor precise fazer mais nada.

Atenção: A varredura secreta tem dois lados. Várias campanhas de worms incluíram scanners secretos prontos para uso, como o TruffleHog, para vasculhar hosts infectados em busca de credenciais — a mesma ferramenta que os defensores utilizam, só que apontada na direção oposta.

Essa curva de crescimento é o argumento a favor de pontos de controle que não dependam do conhecimento prévio de quais pacotes são maliciosos. A triagem de pacotes antes que eles sejam resolvidos e a verificação de artefatos publicados em relação ao código-fonte verificado podem detectar classes inteiras de comprometimento sem esperar que um aviso seja emitido. Esse é o raciocínio por trás do SecureChain para npm.

Mastra e jscrambler mantiveram a tendência

Dois incidentes posteriores, ocorridos em 2026, deixaram claro que o que aconteceu em março não foi um caso isolado. O A invasão do pacote Mastra AI em 17 de junho e o ataque ao jscrambler em 11 de julho ocorreram por meio de acesso do lado do servidor, e não por uma vulnerabilidade presente no código de algum usuário.

A Microsoft atribuiu o ataque ao Mastra ao Sapphire Sleet, nome que dá à atividade que o Google rastreia como UNC1069. Cerca de onze semanas após o incidente relatado pela Axios, o mesmo cluster voltou à ativa com um roteiro de ataque muito semelhante. Uma conta de um ex-colaborador, que ainda detinha direitos de publicação no escopo @mastra, foi usada para republicar mais de 140 pacotes, e a única alteração em cada um deles foi a adição de uma única dependência chamada easy-day-js, uma biblioteca semelhante ao dayjs que continha um gancho pós-instalação malicioso. O código da biblioteca nunca foi alterado, o que é exatamente o que aconteceu com o axios.

A Sonatype relatou mais de 454.600 novos em repositórios de código aberto no npm, PyPI e outros registros somente em 2025; portanto, esse volume não é novidade. O que a onda recente mostra é a rapidez com que o acesso comprometido a canais de publicação transforma esse volume em algo que chega à fase de compilação.

O que teria realmente impedido isso?

Aqui estão seis medidas de controle em análise, avaliadas com imparcialidade em relação a um ataque de três horas no lado da publicação.

–ignore-scripts conquistou seu espaço, e o ecossistema já se adaptou a isso. O npm 12 foi lançado em 8 de julho de 2026, com os scripts de instalação de dependências desativados por padrão, incluindo o implícito node-gyp que um arquivo binding.gyp costumava acionar; assim, o npm 12 bloqueia essa carga sem que ninguém precise se lembrar de um sinalizador. Dependências que realmente precisam de scripts de instalação ou de compilação nativa agora precisam ser aprovadas explicitamente, o que vale a pena ser feito de forma deliberada antes que uma atualização interrompa silenciosamente um pipeline.

Ainda não é uma correção geral — o código malicioso presente no corpo do módulo é executado no momento em que algo importa o pacote, independentemente de o script estar bloqueado ou não. O vulnerabilidade do jscrambler em julho é a ilustração mais clara disso. As primeiras versões maliciosas eram executadas a partir de um gancho de pré-instalação e, em seguida, ainda durante a mesma janela de publicação de três horas, o invasor inseriu o dropper idêntico no próprio código do pacote, de modo que ele fosse acionado quando o pacote fosse importado ou sua CLI fosse executada. Bloquear scripts de instalação é necessário. Mas não é suficiente.

A disciplina relacionada ao arquivo de bloqueio precisa de uma ressalva mais ampla, pois é a medida de controle que a maioria das equipes presume já ter implementado.

Atenção: Um intervalo com o símbolo de inserção, como ^1.7.0 no arquivo package.json será facilmente resolvido como uma versão de patch maliciosa quando nada a fixar. Um arquivo de bloqueio confirmado impede isso, e o npm ci é a maneira mais rigorosa de instalar a partir de um arquivo de bloqueio, já que ele se recusa a ser executado quando o arquivo de bloqueio e o package.json não estiverem de acordo, em vez de simplesmente alterar a resolução sem aviso. A proteção desaparece no momento em que o arquivo de bloqueio é regenerado ou atualizado para uma versão que inclua a vulnerabilidade. Muitos pipelines deixam de verificar pelo menos um desses itens.

A proveniência é útil neste caso e, diante desse modo específico de falha, ela mostra seu valor.

Você sabia? O npm oferece suporte à certificação de proveniência baseada no Sigstore para pacotes publicados a partir da CI, e você pode verificar o que já possui com um único comando: npm audit signatures.

Vale a pena ser preciso sobre o que isso comprova. A proveniência verifica se um artefato se originou da fonte e do fluxo de trabalho de compilação que alega ter, o que é uma questão diferente e muito mais fácil de responder do que se o código contido nele é malicioso. No caso do axios, isso teria ajudado, pois a última versão 1.x limpa possuía proveniência, ao passo que a versão maliciosa não, tendo sido enviada manualmente com um token roubado, em vez de seguir o fluxo de trabalho de CI do projeto. No entanto, isso não constitui um controle contra malware. As ondas do 2026 Mini Shai-Hulud enviaram pacotes maliciosos com proveniência válida, pois o pipeline que os compilou havia realmente sido comprometido.

O que mudar antes do próximo?

Nada disso exige uma reformulação da plataforma. Escolha com base na situação atual do seu pipeline.

Se seus arquivos de bloqueio tiverem sido confirmados de forma inconsistente, corrija isso primeiro e mude a CI para npm ci. É uma das medidas de controle mais simples da lista e teria evitado esse incidente específico de imediato.

Se você já estiver executando o npm ci em todos os ambientes, adicione um período de quarentena para novos lançamentos. O npm lançou um min-release-age desde a versão 11.10.0, e o pnpm 11 transforma minimumReleaseAge ativado com um dia por padrão, embora a instalação não falhe a menos que você mesmo defina o valor, e a Unit 42 recomenda reter qualquer coisa publicada nas últimas 24 a 72 horas , com base no fato de que a maioria dos pacotes maliciosos é identificada e removida dentro desse intervalo. Isso não teria detectado tudo, já que o worm Shai-Hulud original levou dias para ser totalmente eliminado, mas cobre os casos mais comuns.

Se você mesmo publica pacotes, ative a proveniência e mude para a publicação confiável com OIDC, em vez de usar tokens de publicação de longa duração. O invasor do axios contornou o fluxo de trabalho normal de publicação via OIDC do projeto usando um token clássico roubado, o que constitui um argumento válido para a aposentadoria total desses tokens. Você faz parte da cadeia de suprimentos de outra pessoa, quer pense nisso dessa forma ou não.

E se seus agentes de compilação possuírem credenciais de funções na nuvem, reduza o prazo de validade dessas credenciais com prioridade. Essa é a verdadeira diferença entre uma instalação malfeita e um relatório de incidente.

O problema é que muitos dos controles preventivos mais eficazes ocorrem antes ou no momento da resolução, enquanto a maior parte do que as equipes já investiram visa detectar os problemas após o fato. Isso não é uma crítica à análise de composição de software, que cumpre a função para a qual foi criada. Trata-se de um problema de tempo, e problemas de tempo não são resolvidos simplesmente adicionando mais uma verificação.

Seu desempenho pode variar dependendo da urgência com que a organização realmente precisa de novas versões das dependências. Equipes que lançam ferramentas de IA baseadas em pacotes upstream que evoluem rapidamente arcam com um custo real devido aos períodos de quarentena. Equipes que trabalham com plataformas internas de evolução mais lenta arcam com um custo muito menor e, muitas vezes, descobrem que já estavam três semanas atrasadas em relação às versões secundárias e que ninguém havia percebido.

O próximo já está no ar em algum lugar

Três horas não parecem muito tempo até você contar as instalações que ocorreram nesse intervalo. Essa é a verdadeira lição aqui, não a atribuição à Coreia do Norte nem a classificação do worm. É a lacuna entre a publicação e a descoberta, e o quão pouco existe nesse intervalo por padrão.

O Axios chamou a atenção. Vulnerabilidades menores tendem a receber muito menos atenção. Elas são removidas do registro sem causar grande alvoroço, e quem já as instalou precisa avaliar por conta própria o risco a que está exposto. A próxima, localizada quatro níveis abaixo na árvore de dependências de alguém, também não vai se anunciar.

A verificação baseada em alertas atinge seu máximo potencial quando a ameaça já é conhecida. Detectar um ataque à cadeia de suprimentos do npm enquanto ele ainda está ocorrendo significa realizar a verificação no momento da instalação, em vez de esperar que os dados dos alertas identifiquem o pacote primeiro. Essa é a lacuna que o SecureChain para npm foi desenvolvido para preencher.

Perguntas frequentes

O que é um ataque à cadeia de suprimentos do npm?

Um ataque à cadeia de suprimentos do npm consiste no comprometimento de um pacote no registro antes mesmo que ele chegue até você, geralmente por meio de credenciais de publicação roubadas, uma conta de mantenedor invadida ou falsificação de namespace, e não por causa de uma falha no seu próprio código.

O que aconteceu com o vazamento de dados da Axios?

Duas versões maliciosas do axios, 1.14.1 e 0.30.4, foram lançadas em 31 de março de 2026 e retiradas do ar cerca de três horas depois. Ambas injetavam uma dependência chamada plain-crypto-js , que instalava um trojan de acesso remoto multiplataforma por meio de um gancho pós-instalação. O Grupo de Inteligência contra Ameaças do Google atribuiu o ataque ao UNC1069, e a Microsoft rastreia atividades relacionadas como Sapphire Sleet. As versões seguras para uso são a 1.14.0 e a 0.30.3.

O npm audit detecta pacotes maliciosos?

Suas verificações de vulnerabilidade dependem dos dados dos alertas do registro; portanto, não podem alertá-lo sobre uma versão recém-comprometida até que essa versão tenha sido identificada e registrada. No caso do axios, um alerta foi registrado dentro do prazo de três horas, mas não foi possível reverter as instalações que já haviam ocorrido. Assinaturas do npm audit é uma verificação separada e mais útil neste caso, já que verifica as assinaturas do registro e os atestados de proveniência.

Um arquivo de bloqueio protege contra o sequestro de uma versão do npm?

Um arquivo de bloqueio marcado como “committed” impede que uma versão inesperada seja resolvida, e o `npm ci` é a maneira mais rigorosa de fazer a instalação a partir dele, já que se recusa a prosseguir quando o arquivo de bloqueio e o package.json não estiverem de acordo. Essa proteção deixa de existir quando o arquivo de bloqueio é regenerado ou atualizado para uma versão que inclua o compromisso, e o `npm install` é mais flexível, pois pode alterar a resolução e reescrever o arquivo de bloqueio.

O que é o worm Shai-Hulud?

Uma campanha de malware do npm com propagação automática que coleta informações confidenciais de ambientes infectados, identifica tokens de publicação do npm e os utiliza para se inserir em mais pacotes, ampliando o conjunto de sistemas afetados sem que o invasor precise realizar nenhuma ação adicional. Seu código-fonte foi publicado abertamente em maio de 2026, de modo que agora já é comum observar ondas de imitações.

Como posso verificar se um pacote foi compilado por seus verdadeiros mantenedores?

Executar o comando `npm audit signatures` para verificar as assinaturas do registro e, quando houver, os atestados de proveniência. A proveniência pode confirmar que um artefato foi produzido pela fonte e pelo fluxo de trabalho de CI que ele alega ter, o que é uma questão diferente de saber se o código é seguro, já que um pipeline comprometido pode produzir uma compilação devidamente atestada.

Impedir lançamentos não autorizados antes que sejam resolvidos

Confiar apenas em feeds de alertas pode significar ficar sabendo de uma versão maliciosa somente depois que ela já tiver chegado a uma compilação. O SecureChain para npm analisa os pacotes na resolução e os recompila a partir de uma fonte verificada para bloquear artefatos comprometidos e que violam as políticas antes que cheguem a esse ponto. Confira o SecureChain para npme inscreva-se no boletim informativo da TuxCare para receber atualizações semanais sobre a cadeia de suprimentos de código aberto.

Resumo

Nome do artigo

O ataque à cadeia de suprimentos do Axios no npm e o que ele revelou

Descrição

Duas versões maliciosas do Axios permaneceram ativas por 3 horas. Veja o que o ataque à cadeia de suprimentos do npm revelou e quais controles realmente o impedem.

Autor

Tim Walker

Nome da editora

TuxCare

Logotipo da editora