Se você já passou algum tempo no mundo do JavaScript, você tocou em axios. É a configuração padrão para solicitações HTTP no Node.js. É tão comum que geralmente o tratamos como parte do próprio idioma. Mas há algumas semanas, o setor entrou em um colapso coletivo. As manchetes começaram a gritar sobre uma vulnerabilidade crítica de 10/10 no Axios — CVE-2026-40175 — que supostamente permitia que invasores contornassem a segurança da AWS e roubassem credenciais na nuvem.

Na Sweent, nosso primeiro passo quando um “10/10" cai é iniciar uma auditoria em todo o portfólio. Seja gerenciando painéis corporativos ou modernizando pilhas de aplicativos antigos, não esperamos que os alertas automatizados nos digam que há um incêndio. Começamos a procurar a fumaça nós mesmos. Mas, ao investigarmos essa vulnerabilidade específica, descobrimos algo que as manchetes sensacionais não viram: para a maioria dos aplicativos modernos, o exploit estava morto assim que chegou.

A anatomia do susto

A vulnerabilidade foi descrita como uma “cadeia de gadgets”. Se você não estiver familiarizado com o termo, pense nele como uma máquina Rube Goldberg para hackers. Você precisa que várias coisas diferentes dêem errado em uma ordem específica para que a explosão final aconteça.

Em teoria, a corrente tinha a seguinte aparência:

• Um invasor encontra uma maneira de causar poluição no protótipo do seu aplicativo.

• O Axios capta esses valores poluídos ao mesclar sua configuração interna.

• Esses valores incluem caracteres CRLF (Carriage Return Line Feed) injetados nos cabeçalhos.

• Esses cabeçalhos induzem o servidor a “contrabando de solicitações” ou a falsificação de solicitações do lado do servidor (SSRF).

• O invasor usa esse SSRF para acessar o AWS Instance Metadata Service (IMDSv2) e sair com suas credenciais na nuvem.

• No papel, esse é um cenário de pesadelo. Se um atacante conseguir acessar 169.254.169.254 de dentro da sua rede, ele é dono da sua infraestrutura. Mas aqui está o problema: teoria e produção são dois lugares muito diferentes.

• Por que seu tempo de execução provavelmente salvou você Ao conduzirmos nossa auditoria, percebemos que a principal primitiva da qual essa exploração se baseia — a injeção de cabeçalho CRLF — é algo que o Node.js vem bloqueando no nível de tempo de execução há anos. O Axios não envia bytes pela rede em si; ele usa o módulo http embutido no Node.js. Quando tentamos reproduzir a exploração em um ambiente padrão, continuamos batendo em uma parede. Especificamente, um TypeError [ERR_INVALID_CHAR] . Se você tentar passar um valor de cabeçalho com um caractere de nova linha para http.request () , o Node.js gerará um erro antes mesmo que a solicitação saia do seu servidor. Não importa o quão “poluída” esteja sua configuração do Axios se o motor subjacente se recusar a dirigir. Verificamos, e as mesmas proteções existem em Bun e Deno. É um caso clássico em que a biblioteca é tecnicamente vulnerável, mas o ambiente é seguro. Até analisamos as descobertas de pesquisadores como Raul Vega Del Valle. Seu trabalho confirmou o que estávamos vendo em nossos laboratórios: em aplicações de produção do mundo real, essa cadeia é quase impossível de alcançar porque o intérprete a interrompe. Então, por que a classificação 10/10? Porque as pontuações do CVE pressupõem o pior ambiente possível, não seu cluster Node 20.x bem corrigido.

A auditoria de Swent

Além da verificação automatizada Você pode perguntar por que nos preocupamos em corrigir se o tempo de execução bloqueia a exploração. A resposta é simples: não apostamos na segurança em uma única camada de defesa. Confiar no Node.js para detectar o erro de uma biblioteca é um mau hábito. Nossa equipe revisou manualmente os arquivos package-lock.json e yarn.lock em cada projeto ativo. Não procuramos apenas o número da versão de axios. Analisamos como o código realmente interagia com a rede. Ferramentas automatizadas como o Dependabot são ótimas, mas não entendem o contexto. Eles não sabem se você escreveu um adaptador personalizado que pode ignorar essas proteções integradas do Node.

• Verificamos se há adaptadores personalizados. Se um aplicativo usa um adaptador Axios personalizado que ignora o cliente http Node.js — talvez para gravar solicitações brutas diretamente em soquetes — a proteção de tempo de execução desaparece.

• Procuramos protótipos de riscos de poluição. Se seu aplicativo é vulnerável à poluição do protótipo, você tem problemas muito maiores do que apenas um bug do Axios. Auditamos como lidamos com JSON.parse e a mesclagem de objetos em todos os aspectos.

• Verificamos nossas configurações da AWS. Mesmo que ocorra um SSRF, garantimos que nossos projetos usem o IMDSv2 com limites estritos de salto. Isso torna o roubo de credenciais significativamente mais difícil, mesmo com uma injeção bem-sucedida.

• Vimos como os cabeçalhos são construídos. Procuramos qualquer lugar em que a entrada do usuário pudesse tocar em uma chave ou valor do cabeçalho sem higienização.

Durante essa janela de 24 horas, movemos todos os projetos para o Axios 1.15.0 ou superior. Vimos a “fadiga de alerta” destruir as equipes de desenvolvimento. Eles recebem uma centena de notificações por semana, a maioria delas sobre dependências de desenvolvimento de baixo risco, e começam a ignorá-las. Tratamos a segurança como uma tarefa de engenharia manual e de alta prioridade para que o ruído não abafe o sinal.

A realidade confusa da cadeia de suprimentos

Esse CVE veio na esteira de outro incidente muito mais assustador do Axios: um sequestro de conta de mantenedor que, na verdade, implantou um Trojan de Acesso Remoto (RAT). Esse foi um verdadeiro ataque à cadeia de suprimentos. Não era uma “cadeia de gadgets” que exigia quatro coincidências para funcionar; era um código malicioso em execução no seu pipeline de compilação.

A comparação dos dois destaca um grande problema na engenharia moderna. O setor tende a reagir exageradamente aos bugs teóricos no nível da biblioteca e, ao mesmo tempo, a reagir de forma insuficiente aos comprometimentos de contas. Passamos mais tempo falando sobre um SSRF teórico do que sobre o fato de um mantenedor primário não ter o 2FA habilitado em sua conta npm.

Manter o delta entre a versão instalada e a versão corrigida mais recente o menor possível é a única maneira de manter a sanidade. Mas você não pode simplesmente executar o npm update às cegas. Vimos atualizações “menores” quebrarem os cabeçalhos de produção ou alterarem a forma como os tempos limite são tratados. É por isso que nossos pipelines de CI/CD incluem testes de regressão e portas de segurança. Se uma atualização for interrompida em um único teste de unidade, ela não avançará.

Quando um bug “crítico” não é crítico?

A classificação “10/10" para esse CVE foi baseada no pior cenário absoluto. Se você presumir que um invasor já comprometeu o protótipo do seu aplicativo, está usando uma pilha de rede personalizada estranha e seus metadados na nuvem estão totalmente abertos, então sim, são 10. Mas para o desenvolvedor comum? É um lembrete para manter suas dependências limpas.

Assumimos projetos legados em que o package.json não foi alterado desde 2022. Essa é uma grande responsabilidade. Cada pacote desatualizado é uma porta deixada destrancada. Fazemos questão de educar nossos parceiros sobre por que essas auditorias são importantes. Não se trata de perseguir todas as manchetes; trata-se de saber exatamente qual código está sendo executado em seu ambiente de produção e por quê.

E sejamos honestos: o Axios está ficando inchado. É uma ótima ferramenta, mas tem muito peso legado para oferecer suporte a navegadores e versões antigas do Node. Às vezes, a melhor solução de segurança não é um patch; é mudar para a API nativa fetch se você estiver em um ambiente de execução moderno do Node. Ele tem menos recursos, mas também tem uma superfície de ataque muito menor.

Nossa comida para levar

A segurança não é um recurso do tipo “configure e esqueça”. É um processo constante de verificação. Temos o prazer de informar que todos os nossos sistemas internos e plataformas gerenciadas foram corrigidos e verificados poucas horas após a divulgação, apesar da baixa probabilidade de exploração real.

Não fizemos o patch apenas porque as notícias nos mandaram. Corrigimos porque a biblioteca em si não deveria permitir valores inseguros, mesmo que o tempo de execução os detecte. É sobre defesa em profundidade. Se a primeira linha de defesa (Axios) falhar, a segunda linha (Node.js) a pegará. Se o segundo falhar, o terceiro (AWS IMDSv2) bloqueia o prêmio. É assim que você constrói sistemas que não caem quando uma biblioteca passa por uma semana ruim.

Se você está preocupado com sua própria árvore de dependências ou se não tem certeza se sua equipe atual está entendendo essas nuances, você provavelmente deveria verificar seu package-lock.json agora mesmo. Você está confiando em um bot para lhe dizer quando está em risco ou tem uma equipe que realmente entende o tempo de execução?