- O que aconteceu no ataque à Axios no npm
- Como uma única linha no ficheiro package.json se tornou o vetor de ataque
- Por que é que a revisão de código tradicional não detectou o ataque à Axios
- Por que o raio de explosão abrange tudo o que o pacote atinge
- Que medidas de segurança teriam alterado o resultado
- Saiba mais sobreSupply Chain Software
- Perguntas mais frequentes
O sequestro de pacotes NPM é um ataque à cadeia de abastecimento de software que transforma a confiança num pacote na via de ataque. Os atacantes não precisam de alterar o código do repositório se conseguirem controlar a conta que publica o pacote.
É isso que torna os pacotes npm de confiança uma superfície de ataque tão poderosa. Quando a conta de um mantenedor é comprometida, todos os projetos que instalam o pacote afetado podem ficar expostos através de uma atualização de dependências de rotina. O incidente da Axios, em março de 2026, demonstrou como uma conta npm comprometida pode colocar em risco mais de 100 milhões de downloads semanais sem alterar o código-fonte da Axios de forma visível.
Compreender como funciona o sequestro de pacotes npm ajuda as equipas de segurança a criar controlos que abordem a verdadeira via de ataque, em vez de se limitarem apenas aos ficheiros de origem que a maioria das equipas analisa.
O que aconteceu no ataque à Axios no npm
O ataque ao Axios no npm consistiu na apropriação da conta de um mantenedor, o que transformou um pacote de confiança num mecanismo de distribuição de malware. O atacante comprometeu a conta npm do principal mantenedor do Axios, alterou o endereço de e-mail registado para um endereço controlado por si e bloqueou o acesso ao mantenedor legítimo.
A operação foi orquestrada e deliberada. Foi publicado um pacote isca cerca de 18 horas antes da ativação do código malicioso, criando um histórico de publicações sem levantar suspeitas imediatas. Em seguida, num intervalo de aproximadamente 39 minutos, o atacante lançou duas versões maliciosas: o axios 1.14.1 para o ramo de versões modernas e o axios 0.30.4 para o ramo de versões antigas.
Ambas as linhas de lançamento foram direcionadas simultaneamente para maximizar a exposição. Essa escolha aumentou a probabilidade de que tanto os ambientes atuais como os antigos baixassem um pacote corrompido através do comportamento normal de atualização.
Como uma única linha no ficheiro package.json se tornou o vetor de ataque
Uma única alteração numa dependência do ficheiro package.json pode constituir todo o percurso de ataque num ataque à cadeia de abastecimento do npm. No incidente com o Axios, não foi necessário alterar nenhum ficheiro-fonte do Axios, uma vez que o comportamento malicioso foi introduzido através de uma nova dependência.
Essa dependência era executada através de um gancho «postinstall» do npm. Assim que uma estação de trabalho de um programador, um pipeline de CI/CD ou um sistema de compilação executasse o comando «npm install», o pacote malicioso podia contactar um servidor controlado pelo atacante, recuperar uma carga útil específica do sistema operativo e iniciar a execução.
As cargas úteis foram preparadas para macOS, Windows e Linux. O ataque foi concebido para funcionar em várias plataformas. Após a execução, o dropper eliminou os seus vestígios e substituiu o ficheiro package.json original por uma versão falsificada, dificultando consideravelmente a análise forense posterior.
Por que é que a revisão de código tradicional não detectou o ataque à Axios
A revisão de código tradicional foi concebida para inspecionar alterações no código-fonte dentro de um repositório, mas esta via de ataque não se encontrava no código-fonte do Axios. O ataque ao Axios não se baseou em alterações visíveis no repositório, uma vez que a lógica maliciosa residia numa dependência separada e não no código-fonte do Axios.
Essa diferença é importante. Um revisor que analisasse a atualização do pacote veria pouco mais do que uma nova linha de dependência no ficheiro package.json. O comportamento malicioso propriamente dito só se manifestava quando a dependência era resolvida e instalada.
É por isso que os ataques a pacotes de confiança são difíceis de detetar apenas através da revisão baseada em comparações. A via de ataque situa-se fora dos ficheiros de código-fonte que a maioria das equipas inspeciona, apesar de o pacote continuar a parecer suficientemente legítimo para passar pelos fluxos de trabalho de desenvolvimento de rotina.
Por que o raio de explosão abrange tudo o que o pacote atinge
O alcance de um pacote npm comprometido não é o próprio pacote. O alcance é tudo aquilo com que o pacote entra em contacto.
Para a maioria das organizações, isso inclui pipelines de CI/CD com permissões elevadas, pontos de acesso de programadores com chaves SSH e tokens de nuvem, servidores de compilação com acesso de gravação a repositórios de artefactos e ferramentas de implementação ligadas a sistemas de produção. Um pacote malicioso não precisa de permanecer dentro da árvore de dependências para causar danos. Basta um único ponto de execução de confiança.
É por isso que o incidente da Axios é relevante para além da gestão de pacotes JavaScript. Uma violação ocorrida após a instalação pode transformar um evento de instalação normal em roubo de credenciais, movimento lateral ou acesso à infraestrutura a jusante.
Fraquezas estruturais reveladas pelo ataque da Axios
O incidente da Axios revelou fragilidades estruturais que são comuns nos ambientes modernos de desenvolvimento de software. Não se trata de casos isolados e raros. São pressupostos comuns em muitas organizações.
Confiança nas identidades dos responsáveis pela manutenção de pacotes
A confiança num pacote npm está frequentemente ligada à conta do mantenedor que publica o pacote. Se essa conta for roubada ou alvo de phishing, o atacante herda a mesma autoridade de publicação que o mantenedor legítimo.
Versões flutuantes de dependências
As versões flutuantes ou fixadas de forma não definitiva aumentam a exposição a versões maliciosas. Uma versão comprometida recém-publicada pode entrar num ambiente automaticamente, sem passar por uma etapa de aprovação deliberada.
Scripts pós-instalação não monitorizados
Os scripts de pós-instalação do npm podem executar código arbitrário com as permissões do processo de instalação. Muitas organizações não verificam nem restringem os scripts do ciclo de vida antes da sua execução.
Pipelines de CI/CD com visibilidade limitada do tempo de execução
Os pipelines de CI/CD têm frequentemente acesso alargado a sistemas internos, infraestruturas de compilação e ambientes na nuvem. Esses pipelines são frequentemente considerados fiáveis por predefinição e raramente são monitorizados quanto a comportamentos maliciosos dos pacotes no momento da instalação.
Pontos de acesso de programadores fora da cobertura de segurança total
Os computadores dos programadores armazenam recursos de elevado valor, incluindo chaves SSH, credenciais de nuvem e tokens empresariais. Os terminais dos programadores são também alvos frequentes de execução, uma vez que podem ter menos visibilidade e menos controlos de execução do que os sistemas de produção.
Armazenamentos de credenciais sem gatilhos de rotação rápida
Um ataque à cadeia de abastecimento de software traduz-se frequentemente numa situação de exposição de credenciais. Muitas equipas ainda não dispõem de fluxos de trabalho fiáveis que identifiquem segredos potencialmente expostos e os substituam imediatamente.
Que medidas de segurança teriam alterado o resultado
Três categorias de controlos de segurança teriam reduzido significativamente o impacto do ataque à Axios. Cada controlo aborda um ponto diferente na cadeia de ataque: execução de pacotes, exposição de credenciais e visibilidade das dependências.
1. Verificação de malware ao nível do pacote antes da instalação
A verificação de malware ao nível do pacote ajuda a impedir a execução de dependências maliciosas antes que estas sejam executadas. Isto é importante nos ataques ao npm, uma vez que os ganchos pós-instalação são executados durante a instalação, o que deixa pouco tempo para uma revisão manual depois de o pacote ter sido descarregado.
A verificação de pacotes, dependências e scripts de ciclo de vida antes da instalação permite identificar malware conhecido, comportamentos suspeitos, vulnerabilidades e segredos codificados antes de o pacote chegar a um terminal de um programador ou a um ambiente de CI/CD.
MetaDefender Software Supply Chain é a solução de segurança da cadeia de abastecimento de software OPSWATpara validar componentes de software, fornecedores e pipelines de compilação. Utiliza deteção de ameaças com múltiplos motores, incluindo a análise múltipla Metascan em mais de 30 motores antivírus, para inspecionar pacotes em busca de malware, vulnerabilidades e segredos codificados antes de estes entrarem no ciclo de vida de desenvolvimento.
2. Gestão proativa de segredos com gatilhos de rotação
A gestão proativa de segredos reduz o impacto de uma violação bem-sucedida. Quando é identificado um pacote suspeito, as equipas precisam de um procedimento de resposta que trate as credenciais locais, as chaves SSH, os tokens e os segredos do pipeline como potencialmente expostos e que os altere rapidamente.
A deteção de segredos codificados de forma rígida contribui para o mesmo objetivo. Um pacote malicioso pode roubar segredos da memória ou do disco, mas os segredos expostos que já se encontram no código ou nas dependências representam mais uma camada de risco que pode ser evitada.
3. Supply Chain e monitorização das dependências
A visibilidade da cadeia de abastecimento ajuda as equipas a detetar alterações inesperadas nos pacotes antes que essas alterações se transformem em incidentes a jusante. As equipas de segurança precisam de saber quais os pacotes que estão instalados, quais as versões fixadas, quais as novas dependências que surgiram e onde esses componentes estão a ser executados.
Sem a visibilidade e a monitorização das dependências, o primeiro indício de uma violação de segurança poderá ser o uso indevido de credenciais ou a utilização indevida da infraestrutura, muito tempo depois de a instalação inicial ter ocorrido.
Saiba mais sobreSupply Chain Software
A segurança da cadeia Software depende da verificação dos pacotes antes da execução, da monitorização de novas dependências e da redução da exposição das credenciais que se segue ao comprometimento de um pacote.
Assista ao webinar sob demanda:Supply Chain Software — Os pontos fracos que os atacantes exploram
Perguntas mais frequentes
O que é um ataque à cadeia de abastecimento do npm?
Um ataque à cadeia de abastecimento do npm consiste na introdução de código malicioso através do ecossistema do npm durante as atividades normais de desenvolvimento de software. Os atacantes costumam conseguir isso ao comprometer uma conta de mantenedor, publicar um pacote enganador ou inserir comportamento malicioso em dependências que os programadores e os sistemas de CI/CD instalam automaticamente.
Como é que os atacantes comprometeram o pacote npm da Axios?
Os atacantes comprometeram a conta npm do principal responsável pela manutenção do axios e utilizaram esse acesso de publicação para lançar versões maliciosas nas ramificações de lançamento 1.x e 0.x. Os atacantes também alteraram o endereço de e-mail da conta para um endereço por eles controlado, o que lhes permitiu manter o controlo do pacote.
O que fez o malware no ataque à Axios?
O malware utilizado no ataque à Axios recorreu a um gancho pós-instalação para ser executado durante o processo «npm install». O gancho contactou um servidor controlado pelo atacante, descarregou um trojan de acesso remoto para macOS, Windows ou Linux, executou-o e, em seguida, tentou apagar os vestígios, substituindo os metadados do pacote por conteúdo falsificado.
Por que é que a revisão de código não detectou o ataque à cadeia de abastecimento da Axios?
A revisão de código não detectou o ataque ao Axios porque a lógica maliciosa não foi introduzida no código-fonte do Axios. A alteração visível ao nível do repositório consistiu numa entrada de dependência no ficheiro package.json, enquanto o malware propriamente dito foi introduzido através de um pacote externo, fora do âmbito normal da revisão do código-fonte.
Como é que as organizações podem detetar pacotes npm maliciosos antes da instalação?
As organizações podem detetar pacotes npm maliciosos antes da instalação, através da análise do conteúdo dos pacotes, das árvores de dependências e dos scripts de ciclo de vida antes da execução. Os controlos eficazes combinam a verificação de malware, a análise de dependências, a aplicação de políticas e a integração com CI/CD, para que os pacotes suspeitos possam ser bloqueados antes de chegarem aos ambientes de desenvolvimento ou de compilação.
A fixação de versões impede ataques à cadeia de abastecimento do npm?
A fixação de versões reduz a exposição a versões maliciosas recém-publicadas, uma vez que limita as atualizações automáticas. A fixação de versões não elimina o risco da cadeia de abastecimento, pois uma versão fixada pode já estar comprometida ou podem ainda existir outras falhas de confiança. A fixação de versões funciona melhor quando combinada com a verificação da integridade, a inspeção de pacotes e os controlos em tempo de execução.
