Axios no npm: o incidente de março de 2026 e as lições para seu site
As versões 1.14.1 e 0.30.4 do Axios foram comprometidas. Entenda o caso e por que a resposta deve incluir builds, máquinas e credenciais.
Equipe CapiHost
· 3 min de leitura
O que você precisa saber
O comprometimento atingiu versões específicas. A investigação deve verificar onde elas foram instaladas, não apenas qual versão está no projeto hoje.
Incidente de 31 de março de 2026
Bibliotecas muito usadas também podem passar por incidentes na distribuição de seus pacotes. O caso do Axios em março de 2026 mostra como uma publicação maliciosa pode alcançar a operação de sites mesmo sem começar por uma falha no código escrito pela empresa.
Para uma equipe que hospeda aplicações, o ponto central é reconstruir o caminho da dependência: qual versão foi instalada, em qual máquina, durante qual build e com quais permissões disponíveis. O nome do pacote, sozinho, não responde essas perguntas.
O que o mantenedor e o aviso oficial registraram
No relato publicado em 2 de abril, o mantenedor confirmou que as versões Axios 1.14.1 e 0.30.4 foram distribuídas em 31 de março de 2026 por meio de sua conta comprometida. Elas incluíram a dependência maliciosa plain-crypto-js@4.2.1 e foram removidas do npm após cerca de três horas.
O GitHub Advisory Database identifica exatamente essas duas versões como malware. Isso não significa que toda versão de Axios seja maliciosa ou que todo site que utiliza a biblioteca tenha sido afetado.
Fontes: Axios: relato do mantenedor sobre o incidente · GitHub Advisory Database: malware no Axios
Por que olhar para o histórico do build
Uma verificação do projeto atual pode mostrar uma versão diferente e ainda deixar uma dúvida: o pacote comprometido passou por um build anterior? Compare os arquivos de dependências, os registros de execução e os artefatos da época. Inclua computadores de desenvolvimento e runners de CI na análise.
Nossa sugestão para agências é guardar a identificação de cada publicação junto do cliente atendido. Esse vínculo permite responder com mais precisão quais sites dependem de um mesmo processo de construção e quais precisam ser investigados primeiro.
Remover o pacote não comprova a recuperação
O aviso do GitHub orienta tratar como comprometida uma máquina em que essas versões tenham sido instaladas ou executadas. Também recomenda trocar segredos e chaves a partir de outra máquina. A remoção do pacote, por si só, não garante que outros componentes maliciosos tenham desaparecido.
A resposta deve ser coordenada com quem administra as máquinas e as credenciais. Preserve evidências, delimite os ambientes atingidos e só então conduza a reconstrução e a retomada. Não reutilize automaticamente um runner suspeito para produzir o próximo artefato.
O que muda na rotina de hospedagem
Estabeleça uma lista de informações necessárias para liberar uma publicação: código revisado, dependências identificadas, origem do build e responsável pela aprovação. Esse processo não precisa ser complexo para ser útil; precisa ser repetível e deixar evidência suficiente.
O caso também reforça que segurança de hospedagem não termina no servidor web. O computador que constrói a aplicação e o fluxo que a publica podem ter acesso decisivo ao serviço. Revise essas etapas junto do plano de atualização e de recuperação.
- Procure as versões específicas e a dependência citada nos registros pertinentes.
- Separe uma ausência no projeto atual de uma comprovação sobre instalações anteriores.
- Comunique conclusões com o escopo investigado e as limitações conhecidas.
Fontes e contexto
Fontes consultadas em 19 de setembro de 2026. Os fatos dos avisos são identificados no texto; exemplos e sugestões de operação são da equipe CapiHost. Versões e orientações podem mudar após a publicação.
Hospedagem e e-mail com a sua marca
Conheça o painel próprio do CapiHost e organize os sites e o e-mail profissional dos seus clientes.
