Foram semanas caóticas para a Axios.
Primeiro, um ataque de grande envergadura à cadeia de abastecimento colocou o pacote sob escrutínio. Depois, poucos dias mais tarde, começaram a surgir notícias sobre uma «vulnerabilidade crítica de nível 10/10» que poderia levar ao comprometimento total da nuvem.
Se leu as notícias, provavelmente já viu afirmações como:
- «Os atacantes podem roubar credenciais da AWS»
- «Contornar o IMDSv2»
- «cadeia de execução remota de código»
Isso não me parece nada bom.
Mas quando se analisa de perto como esta vulnerabilidade se comporta realmente 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 investigador que comunicou a falha, uma coisa fica clara:
Em ambientes Node.js padrão, esta vulnerabilidade não é, na prática, explorável.
A razão é simples: o ataque depende da injeção de cabeçalhos malformados, algo que o Node.js já bloqueia ao nível da execução há anos.
Isso não significa que a vulnerabilidade CVE esteja errada. O problema subjacente identificado pela Axios é real, e corrigi-lo foi a decisão certa. Mas a ideia de que isso leva a um comprometimento fácil da nuvem em ambiente de produção não se sustenta quando analisada com rigor. Na prática, a exploração exigiria condições muito específicas, como um adaptador personalizado que contorne a validação de cabeçalhos do Node.js.
O que afirma o CVE
A CVE-2026-40175 é descrita como uma vulnerabilidade do tipo «cadeia de gadgets»:
- Poluição de protótipos numa dependência
- A Axios deteta valores contaminados
- Injeção de cabeçalho CRLF
- Contrabando de pedidos / SSRF
- Contornar o IMDSv2 da AWS
- Roubo de credenciais → violação da nuvem
Em teoria, é assim:
// Poluição de protótipos noutro local
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");O Axios mescla a configuração → recolhe cabeçalhos contaminados → envia um pedido malicioso.
É essa a teoria.
O que realmente acontece no Node.js
O problema é que esta cadeia falha em ambientes reais.
O Axios utiliza o cliente HTTP integrado do Node.js nos bastidores:
http.request(...)
E o Node.js rejeita há anos os caracteres CRLF nos cabeçalhos.
Se tentares:
http.request({
headers: {
"x-test": "hello\r\nInjected: yes"
}
});Receberá:
TypeError [ERR_INVALID_CHAR]: Caractere inválido no conteúdo do cabeçalho
Isso acontece antes de qualquer pedido ser enviado.
Portanto, a primitiva central da qual a exploração depende — a injeção de cabeçalhos CRLF — já está bloqueada ao nível da execução.
Confirmámos isso com o investigador
Para confirmar esta informação, falámos diretamente com o investigador que comunicou a vulnerabilidade, Raul Vega Del Valle.
A sua conclusão coincide com o que observámos:
- O Node.js bloqueia a injeção de cabeçalhos CRLF
- O mesmo comportamento ocorre no Bun e no Deno
- Consequentemente, a cadeia de ataque não é realisticamente exequível em ambientes padrão
Nas palavras de Raul:
«Numa aplicação real… isso não deveria acontecer… O Node, o Bun ou o Deno simplesmente bloqueiam o CRLF.»
Ele também confirmou que:
«Isso não deveria ser possível em aplicações de produção reais.»
Essa é uma nuance fundamental que falta na maioria das reportagens.
Por que é que o CVE ainda existe?
Então, se não é explorável na prática, por que razão isto é um CVE?
Porque o problema é real ao nível da biblioteca.
Anteriormente, o Axios permitia valores de cabeçalho não seguros. Mesmo que o tempo de execução os bloqueasse, a própria biblioteca não impunha essa restrição.
Como explicou o investigador:
«É verdade no nível da biblioteca, embora não o seja no nível do intérprete», afirma Raul Vega Del Valle
Há também um caso específico que vale a pena mencionar, para completar. O Axios permite aos programadores substituir a forma como os pedidos são enviados utilizando um adaptador personalizado. Em vez de depender do http.request integrado no Node, um adaptador personalizado pode construir e enviar manualmente pedidos HTTP.
Em teoria, se uma aplicação:
- utiliza um adaptador Axios personalizado
- ignora completamente o cliente HTTP do Node
- e escreve pedidos em formato bruto diretamente nos sockets
nesse caso, a validação do cabeçalho também poderia ser contornada. Nesse cenário, a injeção de CRLF poderia voltar a ser possível.
Dito isto, tal requer uma utilização não padrão e a desativação deliberada das proteções integradas. Não se aplica a aplicações típicas do Node.js que utilizam o Axios tal como vem de fábrica.
E quanto ao desvio do IMDSv2?
Esta é a parte da história que mais tem dado que falar e a menos fundamentada na realidade.
Sim, o aviso apresenta um pedido do tipo:
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:
- poluição protótipo
- Injeção de CRLF
- contrabando de pedidos
- sem validação em tempo de execução
No Node.js, essa cadeia é interrompida prematuramente.
O próprio investigador observou que , nesta configuração, não é realisticamente possível contornar o IMDSv2, embora tenha referido que o IMDSv1 poderia merecer uma investigação mais aprofundada.
Por que razão isto foi classificado como crítico
A classificação «10/10» deve-se ao potencial de encadeamento no pior cenário possível, e não à facilidade típica de exploração.
Se partirmos do princípio de que:
- é possível que o protótipo cause poluição
- os cabeçalhos podem ser inseridos
- os serviços internos estão acessíveis
- os pontos de extremidade de metadados estão disponíveis
Nesse caso, sim, o impacto poderá ser grave.
Mas isso são muitas suposições acumuladas.
O que os programadores devem realmente fazer
Não é uma situação em que se deva «largar tudo», mas também não é algo que se deva ignorar.
Deve:
- Atualize para o Axios ≥ 1.15.0
- Verifique as suas dependências quanto a riscos de contaminação de protótipos
- Analisar a exposição a SSRF e o acesso à rede
- Evite depender exclusivamente de proteções em tempo de execução
Concentre-se na verdadeira superfície de ataque, e não apenas nas manchetes sobre o CVE.
