Axios e o Problema das Dependências: Um Ataque à Cadeia de Suprimentos de Software
Uma análise detalhada de como a invasão de uma conta npm disseminou um RAT em 174.000 pacotes em apenas 3 horas, expondo falhas nas práticas de segurança de CI/CD e na confiança cega em dependências. O artigo explora a mecânica do ataque ao Axios, os pontos cegos na segurança e as medidas eficazes para mitigar riscos semelhantes.
MundiX News·17 de abril de 2026·7 min de leitura·👁 11 views
Continuando as discussões com nosso Tech Lead, Dmitry, hoje abordamos como a invasão de uma única conta npm em 3 horas propagou um Remote Access Trojan (RAT) para 174.000 pacotes e por que ferramentas padrão como o NPM Audit não detectaram. Analisamos o incidente com o Axios: a mecânica do ataque, os pontos cegos no CI/CD e o que realmente funciona.
30 de Março de 2026: O Que Aconteceu em 3 Horas
Em 30 de março de 2026, duas versões maliciosas do Axios apareceram no npm: 1.14.1 (tag 'latest') e 0.30.4 (tag 'legacy'). Axios é uma biblioteca JavaScript para requisições HTTP com aproximadamente 100 milhões de downloads por semana e 174.000 pacotes dependentes no npm. Na prática, se um projeto é baseado em Node.js, é altamente provável que ele utilize Axios transitivamente.
Um invasor obteve acesso à conta npm de jasonsaayman, o principal mantenedor da biblioteca. O primeiro sinal de comprometimento foi a mudança do e-mail da conta de jasonsaayman@gmail.com para ifstap@proton.me, e o método de publicação mudou de um pipeline OIDC confiável com proveniência SLSA para uma publicação direta via CLI. Ambos os sinais foram detectados automaticamente pelo Elastic Security Labs através do monitoramento da cadeia de suprimentos.
As versões maliciosas permaneceram no registro por cerca de 3 horas. Durante esse tempo, milhares de equipes conseguiram baixá-las e implementá-las, já que a maioria delas obtém a versão 'latest' sem fixar explicitamente uma versão específica.
Como o Ataque Funciona
plain-crypto-js: Dependência Maliciosa
O invasor não modificou o código do Axios em si. Em vez disso, adicionou o pacote plain-crypto-js como dependência. O esquema ocorreu em duas etapas:
plain-crypto-js@4.2.0: Uma versão "limpa", publicada antecipadamente para criar um histórico de publicações.
plain-crypto-js@4.2.1: Uma versão maliciosa com um postinstall hook: durante a instalação, automaticamente baixava e executava um RAT de segundo estágio a partir do servidor C2 sfrclak[.]com:8000.
O RAT é multiplataforma, com payloads separados para macOS, Windows e Linux. Após estabelecer uma conexão com o C2, ele concede acesso remoto completo à máquina.
Por Que Isso Passou Pela Maioria dos CI/CDs Sem Interrupção
Os pipelines de CI/CD compilam, testam e entregam atualizações sem intervenção humana. Quando uma equipe não fixa uma versão específica de uma dependência, mas especifica a última versão disponível (^1.x.x), o npm resolve a versão 'latest' atual em cada compilação. No período entre 30 e 31 de março, essa era a versão 1.14.1 com o RAT embutido.
A maioria das equipes não possui uma etapa em seu CI/CD que verifique a segurança das dependências antes da compilação. De acordo com o OpenSSF Scorecard 2024, menos de 20% dos projetos de código aberto usam hashes fixos de dependências. A situação não é melhor em projetos comerciais que utilizam esses pacotes.
Por Que o NPM Audit Não Interrompeu o Ataque
O NPM Audit compara os pacotes instalados com um banco de dados de CVEs (Common Vulnerabilities and Exposures). No momento do ataque, nem o Axios 1.14.1 nem o plain-crypto-js 4.2.1 estavam listados nos bancos de dados, pois haviam sido publicados recentemente. O NPM Audit os escaneou e retornou um status 'clean'.
A lógica da ferramenta não está quebrada aqui; ela simplesmente não é aplicável a essa classe de ataques. Os bancos de dados de CVE registram vulnerabilidades conhecidas. Um ataque através da invasão de uma conta publica um pacote formalmente novo que ainda não foi incluído em nenhum banco de dados.
Este incidente foi detectado por uma ferramenta de outra classe: o Elastic Security Labs descobriu o ataque através do monitoramento comportamental, rastreando as mudanças nos metadados dos pacotes (mudança de e-mail, método de publicação, nova dependência em uma versão sem histórico de mudanças).
Dependências: O Novo Perímetro de Segurança
O que falhou no antigo paradigma?
Anteriormente, a responsabilidade era dividida por funções: o líder da equipe ou o arquiteto decidia qual módulo adicionar; o DevOps monitorava o processo de entrega; os especialistas em segurança se envolviam mais tarde com verificações SAST/DAST; os advogados cuidavam das licenças. Cada um verificava sua parte.
O incidente com o Axios revela uma lacuna nesse esquema: ninguém verificou se a conta do mantenedor ainda estava sob o controle de uma pessoa legítima. O nível de confiança nos pacotes assinados não era absoluto; estava vinculado a uma conta específica que poderia ser roubada.
174.000 Pacotes: Por Que a Escala é Tão Grande
Axios está entre os 5 pacotes npm mais baixados. 174.000 pacotes dependem direta ou transitivamente dele. A mecânica é a mesma da era dos CMS com WordPress e Joomla: uma vulnerabilidade no núcleo é a chave para todos os projetos naquela plataforma.
Um projeto Node.js padrão contém 40–60 dependências diretas. Cada uma delas tem suas próprias dependências, em média 5–7 pacotes. Total: 40 × 5 = 200+ pacotes que vivem silenciosamente em seu projeto, e por trás de cada um deles está uma pessoa específica com uma conta.
As dependências transitivas são uma classe separada: pacotes necessários apenas durante a fase de compilação e que não entram em produção. Eles também podem representar uma ameaça e, ao mesmo tempo, não serem o foco da revisão de código.
Como a IA Está Mudando o Equilíbrio de Poder
A IA acelera a escrita de código, ajuda na solução de problemas e automatiza a revisão de código. As mesmas capacidades funcionam contra os defensores: uma rede neural escaneia o código de outra pessoa em busca de vulnerabilidades em minutos, uma tarefa que um especialista experiente costumava levar horas.
A atribuição deste incidente é um threat actor norte-coreano (de acordo com o Google Cloud Threat Intelligence). Não são mais script kiddies de um fórum. Grupos estatais estão usando IA para encontrar pontos de entrada na cadeia de suprimentos, escaneando automaticamente milhares de pacotes em busca de contas fracas de mantenedores.
O número de vulnerabilidades em código open source que ainda não foram identificadas e documentadas é de milhões. De acordo com um estudo do Google Project Zero de 2023, o tempo médio entre a descoberta de uma vulnerabilidade e o patch público é de 25 dias. A IA está encurtando o tempo de busca do lado dos atacantes mais rápido do que as equipes de segurança estão crescendo do lado dos defensores.
O Que Teria Interrompido Este Ataque
npm audit signatures
A equipe verifica as assinaturas criptográficas de cada pacote e confirma que a publicação passou por um pipeline CI/CD oficial com proveniência SLSA, e não através de uma publicação direta via CLI a partir de uma conta modificada.
No caso do Axios 1.14.1, essa verificação teria revelado a anomalia imediatamente: a mudança do método de publicação de OIDC para CLI direto é um sinal claro. Foi esse sinal que o Elastic Security Labs detectou em seu monitoramento.
O Que Precisa Ser Incorporado ao CI/CD
Versões fixas ou hashes de dependências: npm install --frozen-lockfile ou uso de package-lock.json com commit no repositório.
npm audit signatures: Verificação de assinaturas antes de cada compilação.
SAST nas dependências: Análise estática não apenas do seu próprio código, mas também dos pacotes instalados.
Dependabot ou similar: Notificações automáticas sobre vulnerabilidades em dependências com CVEs conhecidos.
Monitoramento comportamental de pacotes: Análise de metadados de lançamentos: mudança de e-mail, mudança de método de publicação, novas dependências sem histórico.
Grandes empresas já estão implementando essas práticas como parte do DevSecOps. Pequenos projetos ainda não. São eles que constituem a maior parte dos 174.000 pacotes afetados.
Conclusão
Em 3 horas, de 30 a 31 de março de 2026, uma conta comprometida de um mantenedor transformou uma biblioteca com 100 milhões de downloads por semana em um vetor de entrega de RAT para macOS, Windows e Linux. O ataque não parou porque a proteção da maioria das equipes funcionou, mas porque o Elastic Security Labs estava realizando monitoramento comportamental e rapidamente iniciou a remoção dos pacotes do registro.
O perímetro da rede, os direitos de acesso, seu próprio código — tudo isso está sob controle há muito tempo. As dependências — código de terceiros, por trás do qual está uma pessoa específica com uma conta — permaneceram fora desse perímetro. O incidente com o Axios fechou esse ponto cego para aqueles que o notaram.
Aqueles que não notaram descobrirão mais tarde, quando algo der errado.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Continuando as discussões com nosso Tech Lead, Dmitry, hoje abordamos como a invasão de uma única conta npm em 3 horas propagou um Remote Access Trojan (RAT) para 174.000 pacotes e por que ferramentas padrão como o NPM Audit não detectaram. Analisamos o incidente com o Axios: a mecânica do ataque, os pontos cegos no CI/CD e o que realmente funciona.
30 de Março de 2026: O Que Aconteceu em 3 Horas
Em 30 de março de 2026, duas versões maliciosas do Axios apareceram no npm: 1.14.1 (tag 'latest') e 0.30.4 (tag 'legacy'). Axios é uma biblioteca JavaScript para requisições HTTP com aproximadamente 100 milhões de downloads por semana e 174.000 pacotes dependentes no npm. Na prática, se um projeto é baseado em Node.js, é altamente provável que ele utilize Axios transitivamente.
Um invasor obteve acesso à conta npm de jasonsaayman, o principal mantenedor da biblioteca. O primeiro sinal de comprometimento foi a mudança do e-mail da conta de jasonsaayman@gmail.com para ifstap@proton.me, e o método de publicação mudou de um pipeline OIDC confiável com proveniência SLSA para uma publicação direta via CLI. Ambos os sinais foram detectados automaticamente pelo Elastic Security Labs através do monitoramento da cadeia de suprimentos.
As versões maliciosas permaneceram no registro por cerca de 3 horas. Durante esse tempo, milhares de equipes conseguiram baixá-las e implementá-las, já que a maioria delas obtém a versão 'latest' sem fixar explicitamente uma versão específica.
Como o Ataque Funciona
plain-crypto-js: Dependência Maliciosa
O invasor não modificou o código do Axios em si. Em vez disso, adicionou o pacote plain-crypto-js como dependência. O esquema ocorreu em duas etapas:
plain-crypto-js@4.2.0: Uma versão "limpa", publicada antecipadamente para criar um histórico de publicações.
plain-crypto-js@4.2.1: Uma versão maliciosa com um postinstall hook: durante a instalação, automaticamente baixava e executava um RAT de segundo estágio a partir do servidor C2 sfrclak[.]com:8000.
O RAT é multiplataforma, com payloads separados para macOS, Windows e Linux. Após estabelecer uma conexão com o C2, ele concede acesso remoto completo à máquina.
Por Que Isso Passou Pela Maioria dos CI/CDs Sem Interrupção
Os pipelines de CI/CD compilam, testam e entregam atualizações sem intervenção humana. Quando uma equipe não fixa uma versão específica de uma dependência, mas especifica a última versão disponível (^1.x.x), o npm resolve a versão 'latest' atual em cada compilação. No período entre 30 e 31 de março, essa era a versão 1.14.1 com o RAT embutido.
A maioria das equipes não possui uma etapa em seu CI/CD que verifique a segurança das dependências antes da compilação. De acordo com o OpenSSF Scorecard 2024, menos de 20% dos projetos de código aberto usam hashes fixos de dependências. A situação não é melhor em projetos comerciais que utilizam esses pacotes.
Por Que o NPM Audit Não Interrompeu o Ataque
O NPM Audit compara os pacotes instalados com um banco de dados de CVEs (Common Vulnerabilities and Exposures). No momento do ataque, nem o Axios 1.14.1 nem o plain-crypto-js 4.2.1 estavam listados nos bancos de dados, pois haviam sido publicados recentemente. O NPM Audit os escaneou e retornou um status 'clean'.
A lógica da ferramenta não está quebrada aqui; ela simplesmente não é aplicável a essa classe de ataques. Os bancos de dados de CVE registram vulnerabilidades conhecidas. Um ataque através da invasão de uma conta publica um pacote formalmente novo que ainda não foi incluído em nenhum banco de dados.
Este incidente foi detectado por uma ferramenta de outra classe: o Elastic Security Labs descobriu o ataque através do monitoramento comportamental, rastreando as mudanças nos metadados dos pacotes (mudança de e-mail, método de publicação, nova dependência em uma versão sem histórico de mudanças).
Dependências: O Novo Perímetro de Segurança
O que falhou no antigo paradigma?
Anteriormente, a responsabilidade era dividida por funções: o líder da equipe ou o arquiteto decidia qual módulo adicionar; o DevOps monitorava o processo de entrega; os especialistas em segurança se envolviam mais tarde com verificações SAST/DAST; os advogados cuidavam das licenças. Cada um verificava sua parte.
O incidente com o Axios revela uma lacuna nesse esquema: ninguém verificou se a conta do mantenedor ainda estava sob o controle de uma pessoa legítima. O nível de confiança nos pacotes assinados não era absoluto; estava vinculado a uma conta específica que poderia ser roubada.
174.000 Pacotes: Por Que a Escala é Tão Grande
Axios está entre os 5 pacotes npm mais baixados. 174.000 pacotes dependem direta ou transitivamente dele. A mecânica é a mesma da era dos CMS com WordPress e Joomla: uma vulnerabilidade no núcleo é a chave para todos os projetos naquela plataforma.
Um projeto Node.js padrão contém 40–60 dependências diretas. Cada uma delas tem suas próprias dependências, em média 5–7 pacotes. Total: 40 × 5 = 200+ pacotes que vivem silenciosamente em seu projeto, e por trás de cada um deles está uma pessoa específica com uma conta.
As dependências transitivas são uma classe separada: pacotes necessários apenas durante a fase de compilação e que não entram em produção. Eles também podem representar uma ameaça e, ao mesmo tempo, não serem o foco da revisão de código.
Como a IA Está Mudando o Equilíbrio de Poder
A IA acelera a escrita de código, ajuda na solução de problemas e automatiza a revisão de código. As mesmas capacidades funcionam contra os defensores: uma rede neural escaneia o código de outra pessoa em busca de vulnerabilidades em minutos, uma tarefa que um especialista experiente costumava levar horas.
A atribuição deste incidente é um threat actor norte-coreano (de acordo com o Google Cloud Threat Intelligence). Não são mais script kiddies de um fórum. Grupos estatais estão usando IA para encontrar pontos de entrada na cadeia de suprimentos, escaneando automaticamente milhares de pacotes em busca de contas fracas de mantenedores.
O número de vulnerabilidades em código open source que ainda não foram identificadas e documentadas é de milhões. De acordo com um estudo do Google Project Zero de 2023, o tempo médio entre a descoberta de uma vulnerabilidade e o patch público é de 25 dias. A IA está encurtando o tempo de busca do lado dos atacantes mais rápido do que as equipes de segurança estão crescendo do lado dos defensores.
O Que Teria Interrompido Este Ataque
npm audit signatures
A equipe verifica as assinaturas criptográficas de cada pacote e confirma que a publicação passou por um pipeline CI/CD oficial com proveniência SLSA, e não através de uma publicação direta via CLI a partir de uma conta modificada.
No caso do Axios 1.14.1, essa verificação teria revelado a anomalia imediatamente: a mudança do método de publicação de OIDC para CLI direto é um sinal claro. Foi esse sinal que o Elastic Security Labs detectou em seu monitoramento.
O Que Precisa Ser Incorporado ao CI/CD
Versões fixas ou hashes de dependências: npm install --frozen-lockfile ou uso de package-lock.json com commit no repositório.
npm audit signatures: Verificação de assinaturas antes de cada compilação.
SAST nas dependências: Análise estática não apenas do seu próprio código, mas também dos pacotes instalados.
Dependabot ou similar: Notificações automáticas sobre vulnerabilidades em dependências com CVEs conhecidos.
Monitoramento comportamental de pacotes: Análise de metadados de lançamentos: mudança de e-mail, mudança de método de publicação, novas dependências sem histórico.
Grandes empresas já estão implementando essas práticas como parte do DevSecOps. Pequenos projetos ainda não. São eles que constituem a maior parte dos 174.000 pacotes afetados.
Conclusão
Em 3 horas, de 30 a 31 de março de 2026, uma conta comprometida de um mantenedor transformou uma biblioteca com 100 milhões de downloads por semana em um vetor de entrega de RAT para macOS, Windows e Linux. O ataque não parou porque a proteção da maioria das equipes funcionou, mas porque o Elastic Security Labs estava realizando monitoramento comportamental e rapidamente iniciou a remoção dos pacotes do registro.
O perímetro da rede, os direitos de acesso, seu próprio código — tudo isso está sob controle há muito tempo. As dependências — código de terceiros, por trás do qual está uma pessoa específica com uma conta — permaneceram fora desse perímetro. O incidente com o Axios fechou esse ponto cego para aqueles que o notaram.
Aqueles que não notaram descobrirão mais tarde, quando algo der errado.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
