Foram algumas semanas caóticas para o Axios.
Primeiro, um grande ataque à cadeia de suprimentos colocou o pacote sob escrutínio. Então, apenas alguns dias depois, manchetes começaram a surgir sobre uma “vulnerabilidade crítica 10/10” que poderia levar a um comprometimento total da Cloud.
Se você leu a cobertura, provavelmente viu afirmações como:
- “atacantes podem roubar credenciais AWS”
- “bypass de IMDSv2”
- “cadeia de execução remota de código”
Isso parece ruim.
Mas quando você analisa de perto como essa vulnerabilidade realmente se comporta em ambientes reais, a história muda.
Após analisar a cadeia de exploração e validar o comportamento com Raul Vega Del Valle, o pesquisador que relatou o problema, uma coisa fica clara:
Em ambientes Node.js padrão, essa vulnerabilidade não é realisticamente explorável.
A razão é simples: o ataque depende da injeção de cabeçalhos malformados, algo que o Node.js já bloqueia no nível de runtime há anos.
Isso não significa que a CVE esteja errada. O problema subjacente no Axios é real, e corrigi-lo foi a decisão certa. Mas a ideia de que isso leva a um comprometimento fácil da Cloud em produção não se sustenta sob escrutínio. Na prática, a exploração exigiria condições muito obscuras, como um adaptador personalizado que ignora a validação de cabeçalho do Node.
O que a CVE Afirma
CVE-2026-40175 é descrita como uma vulnerabilidade de “gadget chain”:
- Poluição de protótipo em uma dependência
- Axios capta valores poluídos
- Injeção de cabeçalho CRLF
- Contrabando de requisições / SSRF
- Bypass de AWS IMDSv2
- Roubo de credenciais → comprometimento da Cloud
Em teoria, parece assim:
// Poluição de protótipo em outro lugar
Object.prototype['x-amz-target'] =
"dummy\r\n\r\nPUT /latest/api/token HTTP/1.1\r\n" +
"Host: 169.254.169.254\r\n" +
"X-aws-ec2-metadata-token-ttl-seconds: 21600\r\n\r\nGET /ignore";
// Código normal da aplicação
axios.get("https://internal.service");Axios mescla a configuração → capta cabeçalhos poluídos → envia uma requisição maliciosa.
Essa é a teoria.
O que realmente acontece no Node.js
O problema é: essa cadeia se quebra em ambientes reais.
Axios usa o cliente HTTP integrado do Node por baixo dos panos:
http.request(...)
E o Node.js rejeita caracteres CRLF em cabeçalhos há anos.
Se você tentar:
http.request({
headers: {
"x-test": "hello\r\nInjected: yes"
}
});Você receberá:
TypeError [ERR_INVALID_CHAR]: Invalid character in header content
Isso acontece antes que qualquer requisição seja enviada.
Então, a primitiva central da qual o exploit depende — injeção de cabeçalho CRLF — já está bloqueada no nível de runtime.
Verificamos isso com o pesquisador.
Para validar isso, conversamos diretamente com o pesquisador que reportou a vulnerabilidade, Raul Vega Del Valle.
A conclusão dele se alinha com o que observamos:
- Node.js bloqueia a injeção de cabeçalho CRLF
- O mesmo comportamento ocorre em Bun e Deno
- Como resultado, a cadeia de ataque não é realmente alcançável em ambientes padrão
Nas palavras de Raul:
“Em uma aplicação do mundo real… não deveria acontecer… Node, Bun ou Deno simplesmente bloqueiam o CRLF.”
Ele também confirmou que:
“Não deveria ser possível em aplicações de produção reais.”
Essa é uma nuance crítica ausente na maioria das coberturas.
Por que a CVE ainda existe
Então, se não é explorável na prática, por que isso é uma CVE?
Porque o problema é real no nível da biblioteca.
Axios anteriormente permitia valores de cabeçalho inseguros. Mesmo que o runtime os bloqueie, a própria biblioteca não impunha essa restrição.
Como o pesquisador explicou:
“É real no nível da biblioteca, embora não seja no nível do interpretador,” diz Raul Vega Del Valle
Há também um caso de borda que vale a pena mencionar para fins de completude. Axios permite que os desenvolvedores substituam a forma como as requisições são enviadas usando um adaptador personalizado. Em vez de depender do http.request integrado do Node, um adaptador personalizado poderia construir e enviar requisições HTTP manualmente.
Em teoria, se uma aplicação:
- usa um adaptador Axios personalizado
- ignora completamente o cliente HTTP do Node
- e escreve requisições brutas diretamente para sockets
então a validação de cabeçalho também poderia ser ignorada. Nesse cenário, a injeção de CRLF poderia se tornar possível novamente.
Dito isso, isso requer um uso não-padrão e uma desativação deliberada das proteções integradas. Isso não se aplica a aplicações Node.js típicas que usam Axios de forma padrão.
E quanto ao bypass do IMDSv2?
Esta é a parte mais divulgada da história e a menos fundamentada na realidade.
Sim, o alerta mostra uma requisição como:
PUT /latest/api/token
Host: 169.254.169.254
X-aws-ec2-metadata-token-ttl-seconds: 21600
Mas para chegar lá, um atacante precisa de:
- prototype pollution
- CRLF injection
- request smuggling
- sem validação em tempo de execução
No Node.js, essa cadeia se rompe cedo.
Até mesmo o pesquisador observou que o bypass do IMDSv2 não é realisticamente alcançável nesta configuração, embora ele tenha mencionado que o IMDSv1 pode valer uma investigação mais aprofundada.
Por que isso foi classificado como crítico
A classificação “10/10” vem do potencial de encadeamento no pior cenário, não da explorabilidade típica.
Se você assumir:
- prototype pollution é possível
- cabeçalhos podem ser injetados
- serviços internos estão acessíveis
- endpoints de metadados estão expostos
Então sim, o impacto poderia ser severo.
Mas são muitas suposições sobrepostas.
O que os desenvolvedores realmente devem fazer
Esta não é uma situação de “largar tudo”, mas também não é algo a ser ignorado.
Você deve:
- Atualize para Axios ≥ 1.15.0
- Audite suas dependências para riscos de prototype pollution
- Revise exposição a SSRF e acesso à rede
- Evite depender apenas de proteções em tempo de execução
Concentre-se na superfície de ataque real, não apenas na manchete do CVE.
