Ces dernières semaines ont été mouvementées pour Axios.
Tout d'abord, une attaque majeure visant la chaîne logistique a attiré l'attention sur ce package. Puis, quelques jours plus tard, des articles ont commencé à faire la une concernant une « vulnérabilité critique notée 10/10 » susceptible d'entraîner cloud totale cloud .
Si vous avez suivi l'actualité, vous avez sans doute vu des affirmations telles que :
- « Les pirates peuvent voler les identifiants AWS »
- « Contournement de l'IMDSv2 »
- « chaîne d'exécution de code à distance »
Ça a l'air pas terrible.
Mais quand on examine de près le comportement réel de cette vulnérabilité dans des environnements concrets, la situation change.
Après avoir analysé la chaîne d'exploitation et vérifié son comportement avec Raul Vega Del Valle, le chercheur qui a signalé le problème, une chose apparaît clairement :
Dans les environnements Node.js standard, cette vulnérabilité ne peut pas être exploitée dans la pratique.
La raison est simple : cette attaque repose sur l'injection d'en-têtes mal formés, ce que Node.js bloque déjà depuis des années au niveau de l'exécution.
Cela ne veut pas dire que la vulnérabilité CVE est erronée. Le problème sous-jacent signalé par Axios est bien réel, et le corriger était la bonne décision. Mais l'idée selon laquelle cela permettrait de cloud facilement cloud en production ne tient pas la route lorsqu'on y regarde de plus près. En pratique, son exploitation nécessiterait des conditions très particulières, telles qu'un adaptateur personnalisé contournant la validation des en-têtes de Node.js.
Ce qu'affirme le CVE
La faille CVE-2026-40175 est qualifiée de vulnérabilité de type « chaîne de gadgets »:
- Pollution des prototypes dans une dépendance
- Axios reprend des valeurs corrompues
- Injection d'en-tête CRLF
- Contournement des requêtes / SSRF
- Contournement de l'IMDSv2 d'AWS
- Vol d'identifiants → cloud
En théorie, cela donne quelque chose comme ça :
// Pollution des prototypes ailleurs
Objet.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 fusionne les paramètres de configuration → récupère les en-têtes corrompus → envoie une requête malveillante.
C'est du moins ce qu'on dit.
Que se passe-t-il réellement dans Node.js ?
Le problème, c'est que cette chaîne se rompt dans des conditions réelles.
En coulisses, Axios utilise le client HTTP intégré à Node :
http.request(...)
Et Node.js refuse depuis des années les caractères CRLF dans les en-têtes.
Si vous essayez :
http.request({
headers: {
"x-test": "hello\r\nInjected: yes"
}
});Vous bénéficierez de :
TypeError [ERR_INVALID_CHAR] : caractère non valide dans le contenu de l'en-tête
Cela se produit avant l'envoi de toute requête.
Ainsi, la technique de base sur laquelle repose cette faille — l'injection d'en-têtes CRLF — est déjà bloquée au niveau de l'exécution.
Nous avons vérifié cela auprès du chercheur
Pour vérifier cela, nous avons contacté directement le chercheur qui a signalé cette faille, Raul Vega Del Valle.
Sa conclusion correspond à ce que nous avons observé :
- Node.js empêche l'injection de CRLF dans l'en-tête
- Le même comportement se produit dans Bun et Deno
- Par conséquent, cette chaîne d'attaque n'est pas réellement exploitable dans des environnements standard
Selon les propres mots de Raul :
« Dans une application concrète… cela ne devrait pas se produire… Node, Bun ou Deno bloquent simplement les caractères CRLF. »
Il a également confirmé que :
« Cela ne devrait pas être possible dans les applications de production réelles. »
C'est là une nuance essentielle qui fait défaut dans la plupart des reportages.
Pourquoi le CVE existe-t-il toujours ?
Mais si cela n'est pas exploitable dans la pratique, pourquoi s'agit-il d'un CVE ?
Car le problème se pose bel et bien au niveau des bibliothèques.
Auparavant, Axios autorisait des valeurs d'en-tête non sécurisées. Même si le moteur d'exécution les bloquait, la bibliothèque elle-même n'imposait pas cette contrainte.
Comme l'a expliqué le chercheur :
« C'est vrai au niveau de la bibliothèque, mais pas au niveau de l'interpréteur », explique Raul Vega Del Valle
Il convient également de mentionner un cas particulier, par souci d'exhaustivité. Axios permet aux développeurs de redéfinir la manière dont les requêtes sont envoyées à l'aide d'un adaptateur personnalisé. Au lieu de s'appuyer sur la fonction http.request intégrée à Node, un adaptateur personnalisé peut construire et envoyer manuellement des requêtes HTTP.
En théorie, si une application :
- utilise un adaptateur Axios personnalisé
- contourne complètement le client HTTP de Node
- et envoie des requêtes brutes directement aux sockets
la validation des en-têtes pourrait alors également être contournée. Dans ce cas de figure, l'injection de CRLF pourrait redevenir possible.
Cela dit, cela nécessite une utilisation non standard et la désactivation délibérée des protections intégrées. Cela ne s'applique pas aux applications Node.js classiques qui utilisent Axios tel quel.
Qu'en est-il du contournement de l'IMDSv2 ?
C'est la partie de l'histoire qui fait le plus de bruit et qui est la moins ancrée dans la réalité.
Oui, l'alerte affiche une requête du type :
PUT /latest/api/token
Hôte: 169.254.169.254
X-aws-ec2-metadata-token-ttl-seconds : 21600
Mais pour y parvenir, un pirate informatique doit :
- pollution due aux prototypes
- Injection de CRLF
- contournement des règles
- pas de validation à l'exécution
Dans Node.js, cette chaîne se rompt prématurément.
Le chercheur a lui-même fait remarquer que le contournement de l'IMDSv2 n'était pas vraiment envisageable dans ce contexte, même s'il a indiqué que l'IMDSv1 mériterait peut-être d'être étudié plus en détail.
Pourquoi cela a été jugé critique
La note « 10/10 » correspond au potentiel maximal d'enchaînement des vulnérabilités, et non à la facilité d'exploitation habituelle.
Si l'on part du principe que :
- une pollution due au prototype est possible
- les en-têtes peuvent être insérés
- les services internes sont accessibles
- les points de terminaison des métadonnées sont accessibles
Dans ce cas, oui, les conséquences pourraient être graves.
Mais cela fait beaucoup d'hypothèses qui s'accumulent.
Ce que les développeurs devraient réellement faire
Ce n'est pas une situation qui exige de tout laisser tomber, mais ce n'est pas non plus quelque chose qu'il faut ignorer.
Vous devriez :
- Passez à la version Axios ≥ 1.15.0
- Vérifiez vos dépendances pour détecter les risques de pollution des prototypes
- Vérifier l'exposition au SSRF et l'accès au réseau
- Évitez de vous fier uniquement aux protections d'exécution
Concentrez-vous sur la surface d'attaque réelle, et pas seulement sur les titres concernant les CVE.
