A comunidade de desenvolvimento JavaScript foi abalada por uma grave violação de segurança envolvendo o Axios, a biblioteca cliente HTTP mais popular do ecossistema. Atacantes conseguiram inserir um trojan de acesso remoto multiplataforma em versões falsas da ferramenta, expondo milhões de sistemas e equipes ao redor do mundo. Este incidente destaca a fragilidade da cadeia de suprimentos de software, mesmo para projetos que implementam as melhores práticas de segurança.
O Ataque Sofisticado ao Axios e o Trojan Multiplataforma
No que foi descrito por StepSecurity e Socket como um dos ataques de cadeia de suprimentos mais sofisticados já documentados contra um pacote npm de alto nível, hackers roubaram um token de acesso npm de longa duração pertencente ao principal mantenedor do Axios, @jasonsaayman. Utilizando esta credencial, eles publicaram duas versões maliciosas que permaneceram ativas no registro npm por aproximadamente três horas. Durante esse curto período, o malware visou sistemas macOS, Windows e Linux, instalando um trojan de acesso remoto (RAT) capaz de operar em diversas plataformas.
A Infiltração e as Consequências Imediatas
Os atacantes agiram de forma cirúrgica. Eles tomaram controle da conta npm do mantenedor, alteraram o e-mail associado para um endereço ProtonMail anônimo e publicaram os pacotes envenenados diretamente pela interface de linha de comando (CLI) do npm. Essa tática permitiu que contornassem completamente o pipeline de CI/CD (Integração Contínua/Entrega Contínua) baseado no GitHub Actions do projeto. Curiosamente, o código-fonte original do Axios nunca foi tocado. Em vez disso, as branches de lançamento maliciosas receberam uma nova dependência, plain-crypto-js@4.2.1, que, embora não importada pelo código, continha um script postinstall para soltar o RAT na máquina do desenvolvedor.
A preparação para o ataque foi meticulosa. Dezoito horas antes dos lançamentos do Axios, os atacantes publicaram uma versão limpa de plain-crypto-js usando uma conta npm separada, criando um histórico de publicação para evitar alertas de scanners de novos pacotes. As duas branches maliciosas foram lançadas em um intervalo de 39 minutos, com payloads pré-construídos para as três plataformas. Após a execução, o malware se autoapagava e substituía o arquivo package.json por uma versão limpa, dificultando a inspeção forense. A plataforma de segurança Huntress detectou as primeiras infecções apenas 89 segundos após o pacote malicioso ser disponibilizado, confirmando ao menos 135 sistemas comprometidos entre seus clientes durante a janela de exposição.
Falha na Fortaleza: Por que Defesas Modernas Não Foram Suficientes
O caso Axios é particularmente alarmante porque o projeto havia adotado as melhores práticas de segurança recomendadas pela comunidade. As versões legítimas do Axios 1.x eram lançadas através do GitHub Actions usando o mecanismo OIDC Trusted Publisher do npm, cuja documentação oficial vincula criptograficamente cada publicação a um fluxo de trabalho de CI/CD verificado. O projeto também possuía atestações de proveniência SLSA. Por todas as métricas modernas, a pilha de segurança parecia robusta.
No entanto, nada disso importou. A análise da Huntress revelou a falha: o projeto ainda passava o NPM_TOKEN como uma variável de ambiente, paralelamente às credenciais OIDC. Quando ambos estavam presentes, o npm silenciosamente priorizava o token de longa duração. Esse token clássico era o método de autenticação real para cada publicação, independentemente da configuração OIDC. Os atacantes simplesmente contornaram o OIDC, aproveitando um caminho de autenticação legado que o npm preferia. Merritt Baer, CSO da Enkrypt AI e ex-vice-CISO da AWS, comentou em entrevista exclusiva ao VentureBeat, “É muito comum que mecanismos de autenticação antigos permaneçam. Controles modernos são implantados, mas se tokens ou chaves legadas não forem desativados, o sistema os favorece discretamente. Assim como vimos com SolarWinds, onde scripts legados ignoraram monitoramentos mais recentes.”
O próprio mantenedor expressou surpresa no GitHub após descobrir o comprometimento: “Estou tentando obter suporte para entender como isso sequer aconteceu. Tenho 2FA/MFA em praticamente tudo com que interajo.” A Endor Labs documentou a diferença forense: o legítimo axios@1.14.0 mostrava proveniência OIDC e um registro de editor confiável, enquanto o malicioso axios@1.14.1 não. Ferramentas que verificassem a proveniência teriam sinalizado a discrepância instantaneamente, mas a verificação de proveniência ainda é um recurso ‘opt-in’, sem um ‘gate’ de registro que rejeitasse o pacote.
Um Padrão Preocupante: Ataques de Cadeia de Suprimentos no npm
Este é o terceiro grande comprometimento da cadeia de suprimentos do npm em sete meses, e todos eles tiveram a mesma raiz: credenciais de mantenedores roubadas. Em setembro de 2025, o worm Shai-Hulud utilizou uma única conta de mantenedor phishing para se replicar em mais de 500 pacotes, coletando tokens npm, credenciais de nuvem e segredos do GitHub. A CISA emitiu um alerta e o GitHub reformulou todo o modelo de autenticação do npm.
Em janeiro de 2026, a pesquisa PackageGate da Koi Security revelou seis vulnerabilidades de dia zero em npm, pnpm, vlt e Bun, que furaram as defesas adotadas após o Shai-Hulud. A integridade do lockfile e o bloqueio de scripts falharam em condições específicas. Três dos quatro gerenciadores de pacotes foram corrigidos em semanas, mas o npm encerrou o relatório. Agora, o Axios. Um token de longa duração roubou a cena, publicando um RAT através de ambas as branches de lançamento, apesar do OIDC, SLSA e de todas as medidas de reforço pós-Shai-Hulud.
Impacto e o Caminho a Seguir
A proliferação do Axios em aproximadamente 80% dos ambientes de nuvem e código – desde front-ends React até pipelines CI/CD e funções serverless – torna este incidente particularmente grave. Empresas, desenvolvedores e o mercado como um todo são impactados. Para empresas, o risco de violação de dados, interrupção de serviço e perdas financeiras é iminente. Desenvolvedores devem ser ainda mais vigilantes, auditando dependências e implementando ferramentas de segurança de cadeia de suprimentos. Para o mercado, o episódio mina a confiança nos repositórios de código aberto e ressalta a necessidade urgente de soluções mais robustas e automáticas para verificar a integridade dos pacotes.
O ataque ao Axios serve como um lembrete contundente de que a segurança da cadeia de suprimentos de software é um desafio multifacetado e em constante evolução. Mesmo com a adoção de defesas modernas, vulnerabilidades em mecanismos legados e a complexidade das configurações podem ser exploradas por atacantes determinados. É imperativo que a comunidade de desenvolvimento e os mantenedores de repositórios como o npm trabalhem juntos para fortalecer as defesas, talvez tornando a verificação de proveniência um requisito e desativando por padrão métodos de autenticação legados. A vigilância e a educação contínua são as chaves para mitigar riscos futuros.
Gostou da notícia? Inscreva-se na nossa newsletter para receber as principais novidades sobre inteligência artificial diretamente no seu e-mail.
