Si vous avez passé du temps dans le monde de JavaScript, vous avez touché axios. Il s'agit du paramètre par défaut pour les requêtes HTTP dans Node.js. C'est tellement courant que nous le considérons généralement comme faisant partie de la langue elle-même. Mais il y a quelques semaines, l'industrie a connu une crise collective. Les gros titres ont commencé à parler d'une vulnérabilité critique 10/10 dans Axios, CVE-2026-40175, qui aurait permis à des attaquants de contourner la sécurité AWS et de voler des informations d'identification dans le cloud.

Chez Sweent, notre première mesure en cas de baisse de « 10/10 » est de lancer un audit à l'échelle du portefeuille. Qu'il s'agisse de gérer des tableaux de bord d'entreprise ou de moderniser des piles d'applications existantes, nous n'attendons pas des alertes automatisées pour nous signaler un incendie. Nous commençons nous-mêmes à chercher la fumée. Mais en explorant cette vulnérabilité spécifique, nous avons découvert une chose qui n'avait pas fait la une des journaux : pour la plupart des applications modernes, l'exploit était mort à son arrivée.

L'anatomie de la peur

La vulnérabilité a été décrite comme une « chaîne de gadgets ». Si vous ne connaissez pas le terme, considérez-le comme une machine Rube Goldberg pour les pirates informatiques. Il faut que plusieurs choses se passent mal dans un ordre précis pour que l'explosion finale se produise.

En théorie, la chaîne ressemblait à ceci :

• Un attaquant trouve un moyen de polluer un prototype dans votre application.

• Axios récupère ces valeurs polluées lors de la fusion de sa configuration interne.

• Ces valeurs incluent les caractères CRLF (Carriage Return Line Feed) injectés dans les en-têtes.

• Ces en-têtes incitent le serveur à « contrebande de requêtes » ou à une falsification de requêtes côté serveur (SSRF).

• L'attaquant utilise ce SSRF pour accéder au service de métadonnées d'instance AWS (IMDSv2) et repartir avec vos informations d'identification cloud.

• Sur le papier, c'est un scénario cauchemardesque. Si un attaquant peut atteindre « 169.254.169.254 » depuis l'intérieur de votre réseau, il est propriétaire de votre infrastructure. Mais voici le hic : la théorie et la production sont deux domaines très différents.

• Pourquoi votre environnement d'exécution vous a probablement sauvé Au cours de notre audit, nous avons réalisé que la primitive principale sur laquelle repose cet exploit, à savoir l'injection d'en-tête CRLF, était bloquée par Node.js au niveau de l'exécution depuis des années. Axios n'envoie pas d'octets sur le fil lui-même ; il utilise le module http intégré dans Node.js. Lorsque nous avons essayé de reproduire l'exploit dans un environnement standard, nous nous sommes heurtés à un mur. Plus précisément, une TypeError [ERR_INVALID_CHAR] . Si vous essayez de transmettre une valeur d'en-tête avec un caractère de nouvelle ligne à http.request (), Node.js renvoie une erreur avant même que la demande ne quitte votre serveur. Peu importe à quel point votre configuration Axios est « polluée » si le moteur sous-jacent refuse de rouler. Nous avons vérifié et les mêmes protections existent à Bun et Deno. Il s'agit d'un cas classique où la bibliothèque est techniquement vulnérable mais où l'environnement est sécurisé. Nous avons même examiné les résultats de chercheurs tels que Raul Vega Del Valle. Ses travaux ont confirmé ce que nous observions dans nos laboratoires : dans les applications de production réelles, cette chaîne est presque impossible à atteindre car l'interpréteur l'arrête complètement. Alors pourquoi cette note de 10/10 ? Parce que les scores CVE supposent le pire environnement possible, pas votre cluster Node 20.x bien patché.

L'audit de Seent

Au-delà du scan automatique Vous vous demandez peut-être pourquoi nous avons pris la peine d'appliquer des correctifs si le moteur d'exécution bloque l'exploit. La réponse est simple : nous ne misons pas sur la sécurité sur une seule couche de défense. S'appuyer sur Node.js pour détecter les erreurs d'une bibliothèque est une mauvaise habitude. Notre équipe a examiné manuellement les fichiers package-lock.json et yarn.lock pour chaque projet actif. Nous n'avons pas simplement cherché le numéro de version d'axios. Nous avons examiné la manière dont le code interagissait réellement avec le réseau. Les outils automatisés tels que Dependabot sont excellents, mais ils ne comprennent pas le contexte. Ils ne savent pas si vous avez écrit un adaptateur personnalisé qui pourrait contourner ces protections intégrées aux nœuds.

• Nous avons vérifié s'il y avait des adaptateurs personnalisés. Si une application utilise un adaptateur Axios personnalisé qui contourne le client « http » Node.js, peut-être pour écrire des requêtes brutes directement dans des sockets, la protection d'exécution disparaît.

• Nous avons recherché des prototypes de risques de pollution. Si votre application est vulnérable à la pollution des prototypes, vous rencontrez des problèmes bien plus graves qu'un simple bogue Axios. Nous avons vérifié la façon dont nous gérons JSON.parse et la fusion d'objets à tous les niveaux.

• Nous avons vérifié nos configurations AWS. Même en cas de SSRF, nous veillons à ce que nos projets utilisent IMDSv2 avec des limites de sauts strictes. Cela rend le vol d'identifiants beaucoup plus difficile, même en cas d'injection réussie.

• Nous avons examiné la façon dont les en-têtes sont construits. Nous avons recherché tous les endroits où la saisie de l'utilisateur pouvait toucher une touche d'en-tête ou une valeur sans désinfection.

Au cours de cette fenêtre de 24 heures, nous avons transféré chaque projet vers Axios 1.15.0 ou une version ultérieure. Nous avons vu la « fatigue des alertes » détruire les équipes de développement. Ils reçoivent une centaine de notifications par semaine, la plupart pour des dépendances à faible risque liées au développement, et ils commencent à les ignorer. Nous traitons la sécurité comme une tâche d'ingénierie manuelle hautement prioritaire afin que le bruit ne masque pas le signal.

La réalité confuse de la chaîne d'approvisionnement

Ce CVE fait suite à un autre incident Axios bien plus effrayant : un piratage du compte d'un responsable qui a en fait déployé un cheval de Troie d'accès à distance (RAT). Il s'agissait d'une véritable attaque contre la chaîne d'approvisionnement. Il ne s'agissait pas d'une « chaîne de gadgets » qui nécessitait quatre coïncidences pour fonctionner ; il s'agissait d'un code malveillant qui s'exécutait dans votre pipeline de construction.

La comparaison des deux met en évidence un problème majeur de l'ingénierie moderne. Le secteur a tendance à réagir de manière excessive aux bogues théoriques au niveau des bibliothèques tout en réagissant de manière insuffisante aux compromissions de comptes. Nous avons passé plus de temps à parler d'un SSRF théorique qu'au fait qu'un mainteneur principal n'avait pas activé l'authentification à deux facteurs sur son compte npm.

Garder l'écart entre votre version installée et la dernière version corrigée aussi petit que possible est le seul moyen de rester sain d'esprit. Mais vous ne pouvez pas simplement exécuter aveuglément npm update. Nous avons vu des mises à jour « mineures » interrompre les en-têtes de production ou modifier la façon dont les délais d'attente sont gérés. C'est pourquoi nos pipelines CI/CD incluent des tests de régression et des barrières de sécurité. Si une mise à jour interrompt un seul test unitaire, elle n'avance pas.

Quand un bogue « critique » n'est-il pas critique ?

La note « 10/10 » attribuée à cette CVE était basée sur le pire scénario absolu. Si vous supposez qu'un attaquant a déjà compromis le prototype de votre application, que vous utilisez une étrange pile réseau personnalisée et que les métadonnées de votre cloud sont largement ouvertes, alors oui, c'est un 10. Mais pour le développeur moyen ? C'est un rappel pour nettoyer vos dépendances.

Nous avons repris des projets existants où le package.json n'avait pas été modifié depuis 2022. C'est une énorme responsabilité. Chaque colis périmé est une porte laissée déverrouillée. Nous mettons un point d'honneur à informer nos partenaires des raisons pour lesquelles ces audits sont importants. Il ne s'agit pas de rechercher chaque titre ; il s'agit de savoir exactement quel code est exécuté dans votre environnement de production et pourquoi.

Et soyons honnêtes : Axios est gonflé. C'est un excellent outil, mais il a beaucoup de poids pour prendre en charge les navigateurs et les versions anciennes de Node. Parfois, le meilleur correctif de sécurité n'est pas un correctif ; il s'agit de passer à l'API native « fetch » si vous utilisez un environnement d'exécution Node moderne. Il possède moins de fonctionnalités, mais sa surface d'attaque est également beaucoup plus petite.

Nos plats à emporter

La sécurité n'est pas une fonction « configurez-la et oubliez-la ». Il s'agit d'un processus de vérification constant. Nous sommes heureux d'annoncer que tous nos systèmes internes et plateformes gérées ont été corrigés et vérifiés dans les heures qui ont suivi la divulgation, malgré la faible probabilité d'exploitation réelle.

Nous n'avons pas simplement patché parce que les actualités nous l'indiquaient. Nous avons corrigé car la bibliothèque elle-même ne devrait pas autoriser les valeurs dangereuses, même si le moteur d'exécution les détecte. Il s'agit d'une défense en profondeur. Si la première ligne de défense (Axios) échoue, la deuxième ligne (Node.js) la rattrape. Si le second échoue, le troisième (AWS IMDSv2) bloque le prix. C'est ainsi que vous créez des systèmes qui ne tombent pas en panne lorsqu'une bibliothèque passe une mauvaise semaine.

Si vous vous inquiétez pour votre propre arbre de dépendances ou si vous ne savez pas si votre équipe actuelle saisit ces nuances, vous devriez probablement consulter votre package-lock.json dès maintenant. Faites-vous confiance à un bot pour vous indiquer quand vous êtes exposé à un risque, ou avez-vous une équipe qui comprend réellement le temps d'exécution ?