Os invasores roubaram um token de acesso npm de longa duração pertencente ao principal mantenedor do axios, a biblioteca cliente HTTP mais popular em JavaScript, e o usaram para publicar duas versões envenenadas que instalam um trojan de acesso remoto multiplataforma. As versões maliciosas têm como alvo macOS, Windows e Linux. Eles permaneceram ativos no registro npm por cerca de três horas antes da remoção.

Axios obtém mais de 100 milhões de downloads por semana. Wiz relata que está presente em aproximadamente 80% dos ambientes de nuvem e código, abrangendo tudo, desde front-ends React até pipelines de CI/CD e funções sem servidor. A Huntress detectou as primeiras infecções 89 segundos depois que o pacote malicioso foi lançado e confirmou pelo menos 135 sistemas comprometidos entre seus clientes durante a janela de exposição.

Este é o terceiro grande npm comprometimento da cadeia de suprimentos em sete meses. Cada um explorou as credenciais do mantenedor. Desta vez, o alvo adotou todas as defesas recomendadas pela comunidade de segurança.

Uma credencial, duas filiais, 39 minutos

O atacante assumiu o controle npm conta de @jasonsaayman, principal mantenedor do axios, mudou o e-mail da conta para um endereço ProtonMail anônimo e publicou os pacotes envenenados por meio npminterface de linha de comando. Isso ignorou totalmente o pipeline CI/CD do GitHub Actions do projeto.

O invasor nunca tocou no código-fonte do Axios. Em vez disso, ambas as ramificações de lançamento receberam uma única nova dependência: plain-crypto-js@4.2.1. Nenhuma parte da base de código o importa. O pacote existe apenas para executar um script pós-instalação que coloca um RAT multiplataforma na máquina do desenvolvedor.

A encenação foi precisa. Dezoito horas antes do lançamento do axios, o invasor publicou uma versão limpa do plain-crypto-js sob um separado npm conta para criar histórico de publicação e evitar alertas de scanner de novos pacotes. Depois veio o 4.2.1 armado. Ambos os ramos de lançamento foram lançados em 39 minutos. Três cargas específicas da plataforma foram pré-construídas. O malware se apaga após a execução e é trocado por um package.json limpo para frustrar a inspeção forense.

StepSecurity, que identificou o comprometimento junto com o Socket, classificou-o como um dos ataques à cadeia de suprimentos mais sofisticados operacionalmente já documentados contra um dos 10 principais npm pacote.

A defesa que existia no papel

Axios fez as coisas certas. Versões 1.x legítimas enviadas por meio do GitHub Actions usando npmO mecanismo OIDC Trusted Publisher do, que vincula criptograficamente cada publicação a um fluxo de trabalho de CI/CD verificado. O projeto continha atestados de proveniência SLSA. Segundo todas as medidas modernas, a pilha de segurança parecia sólida.

Nada disso importava. A Huntress investigou o fluxo de trabalho de publicação e encontrou a lacuna. O projeto ainda passou NPM_TOKEN como uma variável de ambiente junto com as credenciais do OIDC. Quando ambos estão presentes, npm o padrão é o token. O token clássico de longa duração era o método de autenticação real para cada publicação, independentemente de como o OIDC foi configurado. O atacante nunca teve que derrotar o OIDC. Eles contornaram isso. Um token legado estava lá como um caminho de autenticação paralelo, e npma própria hierarquia preferiu-o silenciosamente.

“Pela minha experiência na AWS, é muito comum que antigos mecanismos de autenticação permaneçam”, disse Merritt Baer, ​​CSO da Enkrypt AI e ex-vice-CISO da AWS, em entrevista exclusiva à VentureBeat. “Os controles modernos são implantados, mas se os tokens ou chaves legados não forem retirados, o sistema os favorece silenciosamente. Assim como vimos com o SolarWinds, onde os scripts legados ignoraram o monitoramento mais recente.”

O mantenedor postou no GitHub após descobrir o comprometimento: “Estou tentando obter suporte para entender como isso aconteceu. Tenho 2FA/MFA em praticamente tudo com que interajo.”

Endor Labs documentou a diferença forense. Legítimo axios@1.14.0 mostrou a proveniência do OIDC, um registro de editor confiável e um link gitHead para um commit específico. Malicioso axios@1.14.1 não tinha nenhum. Qualquer ferramenta que verificasse a proveniência teria sinalizado a lacuna instantaneamente. Mas a verificação de proveniência é opcional. Nenhum portão de registro rejeitou o pacote.

Três ataques, sete meses, a mesma causa raiz

Três npm compromissos da cadeia de abastecimento em sete meses. Cada um começou com uma credencial de mantenedor roubada.

O worm Shai-Hulud foi atingido em setembro de 2025. Uma única conta de mantenedor phishing deu aos invasores uma base que se autorreplicou em mais de 500 pacotes, coletando npm tokens, credenciais de nuvem e segredos do GitHub à medida que se espalham. A CISA emitiu um comunicado. GitHub revisado npm’s todo o modelo de autenticação em resposta.

Então, em janeiro de 2026, a pesquisa PackageGate da Koi Security revelou seis vulnerabilidades de dia zero em npm, pnpm, vlte Bun que perfurou as próprias defesas que o ecossistema adotou após Shai-Hulud. A integridade do arquivo de bloqueio e o bloqueio de script falharam em condições específicas. Três dos quatro gerenciadores de pacotes foram corrigidos em semanas. npm fechou o relatório.

Agora axios. Um token de longa duração roubado publicou um RAT em ambas as ramificações de lançamento, apesar do OIDC, SLSA e de todas as medidas de proteção pós-Shai-Hulud em vigor.

npm enviou reformas reais depois de Shai-Hulud. A criação de novos tokens clássicos foi descontinuada, embora os pré-existentes tenham sobrevivido até um prazo difícil de revogação. O FIDO 2FA tornou-se obrigatório, os tokens de acesso granulares foram limitados a sete dias para publicação e a publicação confiável via OIDC deu aos projetos uma alternativa criptográfica às credenciais armazenadas. Juntas, essas mudanças fortaleceram tudo o que está abaixo da conta do mantenedor. O que eles não mudaram foi a própria conta. A credencial continuou sendo o único ponto de falha.

“Comprometimento de credenciais é o tema recorrente em npm violações”, disse Baer. “Este não é apenas um problema de senha fraca. É estrutural. Sem credenciais efêmeras, MFA imposta ou ambientes isolados de construção e assinatura, o acesso do mantenedor continua sendo o elo mais fraco.”

O que o npm enviou versus o que esse ataque passou

O que fazer agora na sua empresa

Os líderes do SOC cujas organizações executam Node.js devem tratar isso como um incidente ativo até que confirmem sistemas limpos. A janela de exposição de três horas caiu durante os horários de pico de desenvolvimento nos fusos horários da Ásia-Pacífico, e qualquer pipeline de CI/CD que executasse npm install durante a noite poderia ter extraído a versão comprometida automaticamente.

“A primeira prioridade é a avaliação de impacto: quais construções e consumidores a jusante ingeriram o pacote comprometido?” Baer disse. “Em seguida, contenção, correção e, finalmente, relatórios transparentes para a liderança. O que aconteceu, o que foi exposto e quais controles impedirão uma repetição. As lições do log4j e do fluxo de eventos mostram que a velocidade e a clareza são tão importantes quanto a correção em si.”

• Verifique a exposição. Pesquise arquivos de bloqueio e logs de CI por axios@1.14.1, axios@0.30.4ou plain-crypto-js. Fixar em axios@1.14.0 ou axios@0.30.3.

• Assuma um compromisso se for atingido. Reconstrua as máquinas afetadas a partir de um estado em boas condições. Gire todas as credenciais acessíveis: tokens npm, chaves AWS, chaves SSH, credenciais de nuvem, segredos CI/CD, valores .env.

• Bloqueie o C2. Adicione sfrclak.com e 142.11.206.73 às listas de bloqueio de DNS e regras de firewall.

• Verifique se há artefatos RAT. /Library/Caches/com.apple.act.mond no macOS. %PROGRAMDATA%\wt.exe no Windows. /tmp/ld.py on Linux. Se encontrado, faça uma reconstrução completa.

• Harden daqui para frente. Aplicar npm ci --ignore-scripts em CI/CD. Exige instalações apenas com lockfile. Rejeite pacotes sem procedência de projetos que a possuíam anteriormente. Audite se os tokens legados coexistem com o OIDC em seus próprios fluxos de trabalho de publicação.

A lacuna de credenciais que ninguém fechou

Três ataques em sete meses. Cada um diferente na execução, idêntico na causa raiz. npmO modelo de segurança do ainda trata as contas individuais dos mantenedores como a âncora de confiança definitiva. Essas contas permanecem vulneráveis ​​ao sequestro de credenciais, não importa quantas camadas sejam adicionadas posteriormente.

“A IA detecta pacotes arriscados, audita a autenticação legada e acelera a resposta do SOC”, disse Baer. “Mas os humanos ainda controlam as credenciais do mantenedor. Nós mitigamos o risco. Nós não o eliminamos.”

O atestado de proveniência obrigatório, onde a publicação manual da CLI está totalmente desabilitada, teria detectado esse ataque antes que ele chegasse ao registro. O mesmo aconteceria com a assinatura multipartidária obrigatória, onde nenhum mantenedor pode lançar um lançamento sozinho. Nenhum dos dois é aplicado hoje. npm sinalizou que desabilitar tokens por padrão quando a publicação confiável está habilitada está no roteiro. Até ser lançado, cada projeto executando o OIDC junto com um token legado terá o mesmo ponto cego que os axios tinham.

O mantenedor do axios fez o que a comunidade pediu. Um token legado que ninguém percebeu ainda estava ativo e prejudicou tudo isso.

Fonte ==> Cyberseo