Ces dernières semaines ont été chaotiques pour Axios.
D'abord, une attaque majeure sur la chaîne d'approvisionnement a mis le package sous surveillance. Puis, quelques jours plus tard, des titres ont commencé à apparaître concernant une “vulnérabilité critique 10/10” qui pourrait entraîner une compromission totale du cloud.
Si vous avez lu les articles, vous avez probablement vu des affirmations telles que :
- « les attaquants peuvent voler des identifiants AWS »
- « contournement d'IMDSv2 »
- « chaîne d'exécution de code à distance »
Cela semble grave.
Mais si l'on examine de près le comportement réel de cette vulnérabilité dans des environnements réels, le récit change.
Après avoir analysé la chaîne d'exploitation et validé le comportement avec Raul Vega Del Valle, le chercheur qui a signalé le problème, une chose est claire :
Dans les environnements Node.js standards, cette vulnérabilité n'est pas réalistement exploitable.
La raison est simple : l'attaque repose sur l'injection d'en-têtes malformés, ce que Node.js bloque déjà au niveau du runtime depuis des années.
Cela ne signifie pas que le CVE est erroné. Le problème sous-jacent dans Axios est réel, et le corriger était la bonne décision. Cependant, l'idée que cela mène à une compromission facile du cloud en production ne résiste pas à un examen approfondi. En pratique, l'exploitation nécessiterait des conditions très obscures, comme un adaptateur personnalisé qui contourne la validation des en-têtes de Node.
Ce que le CVE affirme
CVE-2026-40175 est décrite comme une vulnérabilité de type “chaîne de gadgets” :
- Pollution de prototype dans une dépendance
- Axios récupère les valeurs polluées
- Injection d'en-tête CRLF
- Falsification de requête / SSRF
- Contournement d'AWS IMDSv2
- Vol de credentials → compromission du cloud
En théorie, voici ce que cela donne :
// Pollution de prototype ailleurs
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";
// Code d'application normal
axios.get("https://internal.service");Axios merge la configuration → récupère les en-têtes pollués → envoie une requête malveillante.
C'est la théorie.
Ce qui se passe réellement dans Node.js
Le problème est le suivant : cette chaîne se brise dans les environnements réels.
Axios utilise en interne le client HTTP intégré de Node :
http.request(...)
Et Node.js rejette les caractères CRLF dans les en-têtes depuis des années.
Si vous essayez :
http.request({
headers: {
"x-test": "hello\r\nInjected: yes"
}
});Vous obtiendrez :
TypeError [ERR_INVALID_CHAR]: Invalid character in header content
Cela se produit avant l'envoi de toute requête.
Ainsi, le mécanisme essentiel dont l'exploit dépend — l'injection d'en-tête CRLF — est déjà bloqué au niveau de l'exécution.
Nous l'avons vérifié avec le chercheur
Pour valider cela, nous avons discuté directement avec le chercheur qui a signalé la vulnérabilité, Raul Vega Del Valle.
Sa conclusion concorde avec ce que nous avons observé :
- Node.js bloque l'injection d'en-tête CRLF
- Le même comportement se produit dans Bun et Deno
- En conséquence, la chaîne d'attaque n'est pas réalistement atteignable dans des environnements standards
Selon les mots de Raul :
“Dans une application du monde réel… cela ne devrait pas arriver… Node, Bun ou Deno bloquent simplement le CRLF.”
Il a également confirmé que :
“Cela ne devrait pas être possible dans des applications de production réelles.”
C'est une nuance critique qui fait défaut dans la plupart des analyses.
Pourquoi le CVE existe toujours
Alors si ce n'est pas exploitable en pratique, pourquoi est-ce un CVE ?
Parce que le problème est réel au niveau de la bibliothèque.
Axios autorisait auparavant des valeurs d'en-tête non sécurisées. Même si le runtime les bloque, la bibliothèque elle-même n'appliquait pas cette contrainte.
Comme l'a expliqué le chercheur :
“C'est réel au niveau de la bibliothèque, bien que ce ne soit pas au niveau de l'interpréteur,” déclare Raul Vega Del Valle
Il y a aussi un cas limite qui mérite d'être mentionné pour être complet. Axios permet aux développeurs de remplacer la manière dont les requêtes sont envoyées en utilisant un adaptateur personnalisé. Au lieu de s'appuyer sur http.request intégré de Node, un adaptateur personnalisé pourrait construire et envoyer manuellement des requêtes HTTP.
En théorie, si une application :
- utilise un adaptateur Axios personnalisé
- contourne entièrement le client HTTP de Node
- et écrit des requêtes brutes directement dans des Socket
alors la validation des en-têtes pourrait également être contournée. Dans ce scénario, l'injection CRLF pourrait redevenir possible.
Cela dit, cela nécessite une utilisation non standard et une désactivation délibérée des protections intégrées. Cela ne s'applique pas aux applications Node.js typiques utilisant Axios par défaut.
Qu'en est-il du contournement d'IMDSv2 ?
C'est la partie la plus médiatisée de l'histoire et la moins ancrée dans la réalité.
Oui, l'avis de sécurité montre une requête telle que :
PUT /latest/api/token
Host: 169.254.169.254
X-aws-ec2-metadata-token-ttl-seconds: 21600
Mais pour y parvenir, un attaquant a besoin de :
- prototype pollution
- Injection CRLF
- Détournement de requêtes
- aucune validation en temps d'exécution
Dans Node.js, cette chaîne se brise prématurément.
Même le chercheur a noté que le contournement d'IMDSv2 n'est pas réalistement réalisable dans cette configuration, bien qu'il ait mentionné qu'IMDSv1 pourrait mériter une enquête plus approfondie.
Pourquoi cela a été classé comme critique
La note de « 10/10 » provient du potentiel d'enchaînement dans le pire des cas, et non de l'exploitabilité typique.
Si vous supposez :
- la pollution de prototype est possible
- des en-têtes peuvent être injectés
- les services internes sont accessibles
- les points de terminaison de métadonnées sont exposés
Alors oui, l'impact pourrait être grave.
Mais cela représente beaucoup d'hypothèses superposées.
Ce que les développeurs devraient réellement faire
Ce n'est pas une situation où il faut tout laisser tomber, mais ce n'est pas non plus quelque chose à ignorer.
Vous devriez :
- Mettre à niveau vers Axios ≥ 1.15.0
- Auditez vos dépendances pour détecter les risques de pollution de prototype
- Examinez l'exposition SSRF et l'accès réseau
- Évitez de vous fier uniquement aux protections en temps d’exécution
Concentrez-vous sur la véritable surface d'attaque, et non seulement sur le titre du CVE.
