CVE-2026-40175, Injection d'en-tête Axios et problème de frontière de confiance

Axios a connu un début brutal en avril 2026. Le 31 mars, deux versions malveillantes d'Axios, 1.14.1 et 0.30.4, ont été publiées sur npm par l'intermédiaire d'un compte de responsable compromis et ont été supprimées par la suite. Une semaine plus tard, Axios a publié la version 1.15.0 avec deux correctifs de sécurité critiques, l'un pour un problème de NO_PROXY Un bogue de normalisation suivi comme CVE-2025-62718 et un autre pour CVE-2026-40175, la chaîne de gadgets d'injection d'en-tête qui retient actuellement l'essentiel de l'attention. Cette séquence est importante car de nombreuses équipes trient le "risque Axios" comme s'il s'agissait d'un seul problème. Ce n'est pas le cas. Il y a une compromission de la chaîne d'approvisionnement, un bogue de contournement de proxy lié à SSRF et cette nouvelle chaîne d'injection d'en-tête qui peut, dans le pire des cas, entraîner une pollution de prototype quelque part dans votre pile vers SSRF, la contrebande de requêtes et même l'abus de métadonnées dans le nuage. (GitHub)

Si vous ne prenez qu'une seule mesure opérationnelle après avoir lu ceci, faites-la simple : mettez chaque déploiement d'Axios que vous contrôlez en version 1.15.0 ou ultérieure, puis vérifiez si une partie de votre chemin de requête côté serveur peut hériter de propriétés contrôlées par l'attaquant ou construire des en-têtes à partir d'objets pollués. C'est l'interprétation la plus sûre du rapport officiel, et c'est la seule interprétation qui reste valable même si certains des titres sur les pires cas s'avèrent surestimer l'exploitabilité pratique dans votre environnement d'exécution exact. Le problème ici n'est pas seulement "Axios a un mauvais analyseur" ou "Axios permet l'injection d'en-têtes bruts". Le problème plus profond est qu'Axios se situe sur une frontière de confiance que de nombreuses équipes ne modélisent pas assez soigneusement : fusion d'objets, propriétés héritées, contrôle de la destination sortante, règles de proxy et requêtes internes contenant des informations d'identification. (GitHub)

La description officielle de CVE-2026-40175 est dramatique pour une raison. L'avis de GitHub indique que la bibliothèque peut agir comme une chaîne de gadgets dans laquelle la pollution d'un prototype dans une autre dépendance est escaladée jusqu'à l'exécution de code à distance ou la compromission complète du nuage par le biais d'en-têtes sortants non nettoyés et de la capacité SSRF par défaut. NVD répète la même description de base et indique qu'Axios 1.15.0 est la version corrigée. Mais le dossier public n'est pas net. La page d'avis de GitHub elle-même est incohérente en interne concernant les versions affectées et même incohérente dans la façon dont elle présente la gravité. Cela ne rend pas le problème faux. Cela signifie que les équipes d'ingénieurs responsables devraient lire au-delà du score, comprendre les mécanismes et tester le chemin qui existe réellement dans leur environnement. (GitHub)

CVE-2026-40175 dans un paragraphe

À la base, CVE-2026-40175 est un risque enchaîné côté serveur. L'avis indique qu'Axios peut consommer des propriétés polluées provenant de Object.prototype lors de la fusion des configurations, ne rejettent pas les caractères CRLF dans les valeurs d'en-tête sortantes et transforment ces valeurs en une primitive de contrefaçon de demande ou SSRF. La preuve de concept publiée cible AWS IMDSv2 en créant une seconde requête qui effectue les opérations requises. PUT et utilise ensuite le jeton renvoyé pour récupérer les métadonnées. C'est pourquoi les gros titres parlent d'une compromission du nuage plutôt que d'un bogue générique de validation d'en-tête. Le problème est corrigé dans Axios 1.15.0. (GitHub)

Ce résumé d'un paragraphe est utile, mais il cache toujours la partie la plus difficile du triage. Il ne s'agit pas d'un bogue que vous pouvez évaluer en demandant simplement : "Utilisons-nous Axios ?" Tout dépend si les propriétés polluées peuvent atteindre de manière réaliste la configuration de la requête, si votre runtime laissera ces valeurs d'en-tête survivre suffisamment longtemps pour atteindre le fil, si votre charge de travail peut atteindre les services internes ou le service de métadonnées d'instance, et si vous avez déjà contraint ce chemin avec des contrôles de réseau ou de plate-forme. En d'autres termes, l'avis décrit la chaîne maximale crédible. Votre véritable tâche consiste à mesurer la chaîne atteignable. (GitHub)

Une façon utile de considérer CVE-2026-40175 est qu'il expose le coût du traitement du HTTP sortant comme "juste un appel de bibliothèque". Dans un système mature, les requêtes sortantes ne sont pas ennuyeuses. Elles peuvent contenir une identité, des cookies de session, des en-têtes signés, des informations de routage internes, des informations d'identification de service à service et l'accès à des destinations internes uniquement. Lorsqu'une bibliothèque qui construit ces requêtes commence à hériter de l'état contrôlé par l'attaquant à partir de la chaîne de prototypes JavaScript, le problème n'est pas simplement une syntaxe malformée. Le problème, c'est qu'une frontière auparavant fiable, le point où votre application construit et émet des requêtes, est devenue programmable par quelque chose en amont que le développeur ne connectera peut-être même jamais au chemin de la requête. C'est exactement la raison pour laquelle cet enregistrement mérite plus d'attention qu'un titre générique de CRLF dans l'en-tête ne le suggère. (GitHub)

Ce que dit l'enregistrement officiel CVE-2026-40175

Le point de départ le plus fiable est l'avis de GitHub et l'entrée de la NVD, car l'enregistrement de la NVD est toujours marqué comme étant en cours d'analyse et renvoie à GitHub en tant que source de l'ANC. L'avis de GitHub indique que le paquet est axiosLa version corrigée est la suivante >=1.15.0la composante vulnérable est lib/adapters/http.jsLa chaîne comprend la pollution de prototype, l'injection d'en-tête à base de CRLF, la contrebande de requêtes, le SSRF et le contournement de l'IMDSv2. Il nomme également les CWE concernées CWE-113, CWE-444 et CWE-918. La NVD reflète ce cadrage et pointe également vers le commit de correction, la pull request, la page de publication et l'avis lui-même. (GitHub)

L'avis comporte également un détail que trop de résumés omettent : il décrit cette situation comme n'exigeant aucune entrée directe de l'utilisateur dans Axios lui-même. L'attaquant n'a pas nécessairement besoin de remettre à Axios un objet d'en-tête malveillant dans le code de l'application que le développeur peut voir. Le modèle de l'avis est qu'une autre bibliothèque vulnérable dans la pile permet à l'utilisateur d'utiliser Axios. Object.prototype et Axios récupère ensuite ces propriétés polluées lorsqu'il fusionne la configuration des requêtes. Il s'agit d'un modèle de menace différent du classique "une valeur d'en-tête contrôlée par l'utilisateur atteint une API de requête". Il est plus silencieux, plus indirect et plus facile à manquer lors de l'examen du code parce que l'appel Axios de l'application peut sembler complètement inoffensif. (GitHub)

Le dossier officiel est également suffisamment confus pour qu'il soit irresponsable de prétendre le contraire. Sur la même page d'avis GitHub, la boîte de métadonnées supérieure indique que les versions affectées sont les suivantes <1.13.2mais le texte de la description dit "Versions affectées : Toutes les versions, v0.x - v1.x", alors que la NVD indique "Avant la version 1.15.0". La présentation de la gravité est également inégale : le texte de la description indique "CVSS 9.9", alors que le panneau de score de l'avis indique 10.0, et NVD rend le vecteur CNA de GitHub comme 10.0 Critique tout en montrant que la propre évaluation de NVD n'est pas encore fournie. Ces incohérences n'invalident pas le dossier. Elles modifient la manière dont une équipe attentive devrait les consulter. La réponse opérationnelle correcte n'est pas de débattre pour savoir si 1.13.2 ou 1.15.0 est la véritable limite. La bonne réponse est de standardiser sur la version 1.15.0 ou plus récente, car tous les chemins officiels s'accordent à dire que la version 1.15.0 contient le correctif. (GitHub)

Ce type d'incohérence ne se limite pas à la paperasserie. Il affecte l'appropriation des risques. Les équipes de sécurité veulent savoir si une image étiquetée Axios 1.13.5 est exposée. Les bots de dépendance veulent un plancher précis. Les équipes chargées des plates-formes veulent savoir si chaque version 0.x est dans le champ d'application. Les équipes d'achat et d'audit veulent un numéro de gravité unique. Ici, le dossier public ne fournit pas cela proprement. Lorsque l'enregistrement est incohérent, votre fenêtre de changement devrait être plus conservatrice, pas moins. Une bonne note interne pour ce CVE est simple : "Traiter toutes les versions d'Axios inférieures à 1.15.0 comme nécessitant une remédiation à des fins de triage CVE, et vérifier en cours d'exécution si la chaîne est atteignable." Cette formulation est honnête vis-à-vis des sources et bien plus sûre que de prétendre que l'ambiguïté n'existe pas. (GitHub)

Voici la façon la plus propre de lire le dossier public :

Source publique	Ce qu'il dit	Ce qu'il faut faire
Métadonnées de l'avis GitHub	Versions concernées <1.13.2, patché >=1.15.0	Ne vous fiez pas uniquement à l'étroitesse de la fourchette
Avis narratif de GitHub	Toutes les versions v0.x - v1.xLa chaîne critique par la pollution des prototypes et l'injection d'en-tête	Traiter le problème comme un risque enchaîné côté serveur
Entrée de la NVD	Avant le 1.15.0fixé en 1.15.0Le record est toujours en cours d'analyse	Utilisation 1.15.0 comme plancher d'assainissement
Note de publication d'Axios	v1.15.0 contient la correction de l'injection de l'en-tête et la correction de l'erreur de l'en-tête. NO_PROXY Fixation du SSRF	Passer directement à la version 1.15.0 ou ultérieure

Le tableau semble banal, mais il reflète la principale leçon d'ingénierie de ce CVE : vous ne pouvez pas automatiser votre jugement en copiant un champ d'une page de consultation. Vous devez réconcilier les données. (GitHub)

Pourquoi CVE-2026-40175 est une chaîne de gadgets et non un bogue autonome ?

L'expression "chaîne de gadgets" fait ici un véritable travail. L'explication de MDN sur la pollution des prototypes est un bon point de vue pour ce CVE, car elle divise le problème en deux phases : la pollution et l'exploitation. Tout d'abord, un attaquant parvient à ajouter ou à modifier des propriétés sur un prototype, souvent Object.prototype. Deuxièmement, le code d'application ordinaire accède à ces propriétés polluées et se comporte différemment de ce que le développeur avait prévu. L'exploit ne provient pas nécessairement du même code que celui qui a créé la pollution. Il provient de la logique de confiance qui consomme ensuite l'état pollué. (MDN Web Docs)

C'est exactement ce que dit l'avis de GitHub à Axios. Selon l'avis, si une autre bibliothèque de la pile permet de polluer les données de Object.prototypeAxios peut ensuite hériter de ces propriétés lorsqu'il fusionne la configuration pour une requête sortante. La requête de l'application peut être codée en dur et sembler parfaitement sûre. La partie dangereuse n'est pas l'URL littérale dans le fichier source. La partie dangereuse est l'état de l'en-tête hérité qui n'était pas censé être là. C'est pourquoi l'avis cite en exemple des bibliothèques en amont telles que qs, minimaliste, iniet analyseur de corps. Le fait que votre pile exacte utilise ou non ces paquets est moins important que le modèle : un bogue de pollution ailleurs devient une arme parce qu'Axios devient le gadget d'exécution plus loin dans la chaîne. (GitHub)

Une fois ce cadrage accepté, le reste de la chaîne devient plus facile à raisonner. La pollution des prototypes permet à l'attaquant de placer des valeurs sur les propriétés héritées. Axios, selon l'avis, fusionne ces propriétés dans les en-têtes. Les valeurs d'en-tête contenant des CRLF ne sont pas neutralisées. Cela signifie qu'une seule valeur d'en-tête peut modifier la structure du flux de requêtes, en divisant ou en faisant passer en contrebande du contenu de requêtes supplémentaires. À partir de là, la chaîne peut se transformer en SSRF ou en contrebande de requêtes vers des destinations que le développeur n'avait pas l'intention de contacter. L'exemple de l'avis qui a le plus d'impact est celui d'AWS IMDSv2, mais le même problème structurel implique également d'autres risques, notamment l'injection de Cookie ou Autorisation vers les points de terminaison de la gestion interne ou en utilisant des en-têtes Hôte pour empoisonner les caches partagés. (GitHub)

C'est pourquoi la CVE-2026-40175 ne doit pas être réduite à une "injection d'en-tête dans Axios". La vulnérabilité se situe à l'intersection de trois modèles de sécurité qui appartiennent souvent à des personnes différentes au sein d'une même équipe. Un propriétaire pense au risque de dépendance et à la pollution des prototypes. Un autre propriétaire pense au HTTP sortant, aux proxies et aux appels de service. Un troisième propriétaire pense à l'accès aux métadonnées dans le nuage et à la segmentation du réseau interne. L'avis d'Axios porte sur ces trois aspects. L'attaque ne devient sérieuse que parce que chaque couche fait confiance à la précédente. La logique applicative fait confiance à l'objet pollué. La logique d'application fait confiance à la bibliothèque HTTP. Le chemin de la requête HTTP est approuvé par le nuage ou le réseau interne parce qu'il provient de la charge de travail elle-même. Les chaînes de gadgets sont dangereuses car elles transforment la composition de confiance en composition d'exploitation. (GitHub)

Une grande partie des problèmes liés à la réponse aux incidents commence lorsque les équipes cherchent le "bogue" au mauvais endroit. Dans le cas d'une vulnérabilité de chaîne de gadgets, l'endroit où les dommages sont visibles n'est souvent pas celui où le contrôle de l'attaquant pénètre pour la première fois dans le système. Dans le cas de la CVE-2026-40175, cela signifie que vous pouvez patcher Axios et ne pas comprendre pourquoi le problème est important. Si votre base de code accepte des clés d'objets arbitraires à partir de chaînes de requête, de blobs JSON, de sorties d'analyseur ou de bibliothèques d'aide et qu'elle réutilise ensuite des objets ordinaires pour représenter les en-têtes, les options de requête ou l'état d'authentification, alors Axios n'est pas votre seul problème de limite. Axios est la partie qui a rendu la chaîne suffisamment évidente pour obtenir un CVE. Les conditions en amont qui rendent de telles chaînes possibles sont souvent dispersées dans la base de code. C'est pourquoi un bon plan de remédiation comprend toujours à la fois des correctifs de bibliothèque et une petite révision de la façon dont votre projet gère les propriétés héritées. (MDN Web Docs)

Vous pouvez voir le même schéma plus large dans l'article de Penligent sur Axios, qui soutient que le problème récurrent n'est pas " Axios est bogué " dans un sens vague, mais qu'Axios se trouve souvent dans des points de décision relatifs à la sécurité autour de la destination, des en-têtes, de la propagation des jetons, de l'analyse syntaxique et de la fusion des objets. Ce cadrage est utile parce qu'il éloigne le triage d'une seule phrase sensationnelle comme " compromission totale du nuage " et l'oriente vers une question plus durable : à quoi Axios est-il censé décider ou transporter exactement dans votre environnement ? Si la réponse inclut des hôtes internes, des points d'extrémité de métadonnées privilégiées ou des informations d'identification de service à service de grande valeur, alors cet enregistrement mérite une attention particulière avant même que vous ne décidiez dans quelle mesure la chaîne publiée est accessible dans la pratique. (penligent.ai)

L'enseignement opérationnel le plus important que l'on peut tirer du cadre de la chaîne de gadgets est qu'il ne faut pas limiter l'examen au code qui dit headers : req.headers ou quelque chose de tout aussi évident. Vous devez également vous pencher sur les fonctions d'aide qui fusionnent les objets de configuration, les wrappers qui construisent des options de requête à partir de sources multiples, les intergiciels d'authentification qui apposent des cookies ou des jetons sur les requêtes sortantes, et tous les endroits qui traitent encore un simple objet JavaScript comme un sac sûr de paires clé-valeur sans vérifier la propriété des clés. Les chaînes de gadgets vivent dans les endroits où la "plomberie ennuyeuse" rencontre l'état hérité. (GitHub)

Comment la chaîne d'injection d'en-tête d'Axios atteint IMDSv2

L'angle AWS n'est pas là pour faire joli. Il est là parce que IMDSv2 modifie ce qu'un "SSRF normal" peut faire. La documentation d'AWS est explicite : pour utiliser IMDSv2, l'appelant envoie d'abord un PUT demande à /latest/api/token avec le X-aws-ec2-metadata-token-ttl-seconds l'en-tête. Le service renvoie un jeton. Les demandes de métadonnées ultérieures doivent alors inclure cet en-tête de jeton. AWS note également que lorsque l'utilisation d'un jeton est requise, les requêtes sans jeton valide reçoivent 401 Non autoriséet le jeton est spécifique à l'instance. (Documentation AWS)

C'est important car de nombreuses primitives SSRF sont plus faibles que ne le suggèrent les titres. De nombreux bogues SSRF permettent à l'attaquant d'influencer l'URL de destination, mais pas la méthode, ni l'ensemble des en-têtes, ni la structure du flux de requêtes brutes. Si tout ce que vous pouvez faire est de forcer un GET à 169.254.169.254IMDSv2 peut vous en empêcher. L'impact de l'avis de GitHub repose sur cette distinction. Le but de la chaîne de contrebande de requêtes basée sur les CRLF n'est pas simplement "d'envoyer une requête aux métadonnées". Il s'agit de construire le matériel de requête supplémentaire spécifique nécessaire pour effectuer l'échange de jetons IMDSv2 qu'un SSRF plus faible ne peut normalement pas effectuer. (GitHub)

C'est également la raison pour laquelle le récit de la preuve de concept de l'avis parle d'une "seconde requête introduite clandestinement". Dans la version de la chaîne présentée par l'avis, la valeur de l'en-tête malveillant ne se contente pas d'injecter une ligne supplémentaire parasite. Elle modifie la structure du flux HTTP sortant de sorte que la demande suivante ressemble à une demande de jeton de métadonnées valide. Une fois que ce jeton existe, l'attaquant peut se tourner vers les cibles de métadonnées habituelles, y compris les informations d'identification du rôle IAM, le cas échéant. Les exemples d'AWS montrent exactement ce flux de jetons et indiquent clairement que le jeton PUT doit inclure l'en-tête TTL et que le jeton doit être réutilisé dans les demandes ultérieures. (GitHub)

Un autre détail subtil d'AWS mérite d'être souligné. AWS indique que l'IMDSv2 PUT sont rejetées si elles contiennent un X-Forwarded-For et que la limite par défaut du nombre de sauts de réponse pour ces en-têtes PUT Il s'agit là de contraintes au niveau de la plateforme, et non de solutions miracles, mais elles illustrent un point important : la forme exacte du chemin de requête a de l'importance. Tous les chemins de requête entre votre processus et les métadonnées ne sont pas équivalents. Les proxys transparents, les sidecars, les transports personnalisés bizarres, les réseaux de conteneurs et les intergiciels qui injectent des en-têtes de transfert peuvent tous modifier la possibilité d'utiliser une chaîne théorique. C'est une raison de plus pour valider dans l'environnement réel au lieu de supposer que le chemin d'impact maximal de l'avis correspond exactement à votre déploiement. (Documentation AWS)

Pour les défenseurs, la leçon pratique est simple. Si votre charge de travail n'a jamais besoin d'accéder aux métadonnées au moment de l'exécution, ne considérez pas l'IMDS comme le problème de quelqu'un d'autre simplement parce que le bogue se trouve "dans Axios". La chaîne publiée n'est effrayante que parce que la limite de la demande sortante et la limite de contrôle du nuage sont si proches l'une de l'autre. La bibliothèque ne vole pas d'elle-même les informations d'identification du nuage. Elle donne potentiellement à un attaquant un moyen de faire communiquer la charge de travail avec un service de plateforme privilégié qui aurait dû être traité comme un territoire hostile du point de vue de l'application. En d'autres termes, CVE-2026-40175 est en partie un bogue de bibliothèque et en partie un rappel que les services de métadonnées locaux font partie de la surface d'attaque de votre application chaque fois que le processus peut les atteindre. (GitHub)

Beaucoup d'articles sur les compromis dans l'informatique dématérialisée aplatissent cette distinction en une seule phrase comme "RCE à la prise de contrôle d'AWS". Cette formulation est attrayante, mais elle cache le milieu. C'est au milieu que les vrais défenseurs travaillent : le processus peut-il atteindre les objectifs suivants ? 169.254.169.254IMDSv2 est nécessaire ; les en-têtes sont-ils contraints ; le chemin de la demande préserve-t-il la structure injectée ; le rôle de l'instance a-t-il des privilèges significatifs ; existe-t-il une politique de sortie ou une isolation de la charge de travail devant les métadonnées ; et l'application a-t-elle même une primitive de pollution ailleurs dans la pile. Tant que vous n'aurez pas répondu à ces questions, vous ne saurez pas si l'histoire de la compromission du nuage de l'avis est un risque atteignable ou un diagramme du pire cas. (GitHub)

Pourquoi le comportement de l'exécution de Node.js modifie le risque pratique

C'est la partie que beaucoup de résumés publics sautent parce qu'elle est plus difficile à transformer en titre. La documentation HTTP actuelle de Node.js indique que les valeurs des en-têtes sont automatiquement validées par le module HTTP, que les valeurs non valides soulèvent un Erreur de typeet que les caractères de valeur non valides sont identifiés par le symbole ERR_INVALID_CHAR. Les documents indiquent même qu'il n'est pas nécessaire d'appeler validateHeaderValue avant de passer des en-têtes à une requête, car le module les valide automatiquement. Il s'agit d'une contrainte forte au niveau de la plateforme pour tout exploit qui dépend des caractères CRLF bruts qui survivent dans une requête HTTP Node standard. (nodejs.org)

Ce comportement n'est pas un tout nouveau changement de renforcement de Node qui a été mis en place hier. La documentation Node.js consultable pour les anciennes versions, y compris les documents de la v9 et de la v10, est déjà décrite. ERR_INVALID_CHAR pour les en-têtes. Cela ne prouve pas que tous les chemins d'exécution possibles se sont toujours comportés de la même manière, mais cela signifie que "Node rejette les caractères d'en-tête invalides" n'est pas une nouvelle condition exotique dont seuls les utilisateurs de pointe bénéficient. Il s'agit d'une propriété documentée de la plateforme depuis des années. (nodejs.org)

Cela crée une véritable tension dans les archives publiques. L'avis d'Axios décrit la chaîne comme si la valeur d'en-tête malformée pouvait être écrite directement dans le socket et transformée en une seconde requête de contrebande. Le correctif d'Axios, quant à lui, renforce explicitement la bibliothèque en rejetant les CRLF dans les valeurs d'en-tête avant que ces valeurs n'atteignent le chemin de la requête sous-jacente. Le résumé de la demande d'extraction indique qu'Axios a ajouté assertValidHeaderValuea appliqué la validation à tous les chemins d'ensemble d'en-tête, y compris les éléments de tableau, et a ajouté ou mis à jour les tests pour l'adaptateur de navigateur, Node rechercher, Node httpet En-têtes Axios. Ce correctif est réel et nécessaire. Mais la documentation Node suggère également que, dans l'utilisation HTTP standard de Node, les valeurs d'en-tête invalides portant des CRLF étaient déjà en conflit avec les propres règles de validation du moteur d'exécution. (GitHub)

La bonne façon de le dire, avec précaution, n'est pas "le CVE est faux" ni "le CVE garantit une compromission facile du nuage". La déclaration prudente est la suivante : l'avis décrit une chaîne du pire cas au niveau de la bibliothèque, mais l'accessibilité pratique de cette chaîne dans un déploiement Node normal dépend de la validation en aval de l'exécution, du comportement de l'adaptateur ou de la logique de transport personnalisée qui bloque l'en-tête malformé avant qu'il ne devienne la structure de la demande sur le fil. C'est exactement le genre de question spécifique à l'environnement à laquelle CVSS ne peut répondre à lui seul. (GitHub)

Il y a là une erreur facile mais dangereuse : supposer que la validation d'exécution rend le correctif facultatif. Ce n'est pas le cas. Tout d'abord, la version officielle corrigée est toujours la 1.15.0, et la bibliothèque a clairement choisi d'appliquer la contrainte elle-même au lieu de s'appuyer sur n'importe quel adaptateur ou runtime situé en dessous d'elle. Deuxièmement, le correctif s'applique à plusieurs adaptateurs, et pas seulement à un chemin de code Node. Troisièmement, les limites de sécurité qui "existent généralement en aval" sont des endroits fragiles pour arrêter la remédiation. Une bonne ingénierie de la sécurité préfère une validation explicite au niveau de la couche où le risque est introduit. Axios s'est clairement rallié à ce jugement lorsqu'il a livré le correctif. (GitHub)

Il convient également de rappeler que de nombreux déploiements d'Axios dans le monde réel n'utilisent pas le chemin le plus ennuyeux possible. Ils peuvent envelopper Axios avec des abstractions personnalisées, le combiner avec des polyfills ou des runtimes alternatifs, l'acheminer à travers des proxys spéciaux, ou transformer les en-têtes avant l'envoi. Le correctif publié et la documentation de Node vous indiquent la bonne question à poser lors des tests : "Est-ce que mon chemin de requête actuel rejette les valeurs d'en-tête contenant des CRLF avant qu'elles ne puissent modifier la structure de la requête ?" C'est un bien meilleur objectif de vérification que de discuter des titres sur les médias sociaux. (nodejs.org)

Une réponse mature à la CVE-2026-40175 comporte donc deux parties. La première partie est mécanique : mettez à jour vers la version 1.15.0 ou plus récente, supprimez la condition d'avis de votre graphe de dépendance, et détectez les régressions futures dans l'IC. La seconde partie est empirique : exécutez un test négatif dans votre propre pile et confirmez que le contenu invalide de l'en-tête est rejeté là où vous pensez qu'il est rejeté. Cette deuxième partie est ce qui transforme un correctif d'un saut de version en un contrôle vérifié. (GitHub)

Ce qu'Axios a changé dans la version 1.15.0

La note de mise à jour v1.15.0 d'Axios est laconique mais importante. Elle indique que la version contient deux correctifs de sécurité critiques, l'un pour la gestion du proxy et l'autre pour l'injection d'en-tête, et mentionne explicitement "Injection d'en-tête : Correction d'une vulnérabilité d'exfiltration de métadonnées dans le nuage sans restriction via une chaîne d'injection d'en-tête". Cela signifie que vous n'avez pas besoin de deviner si les mainteneurs considèrent que cette vulnérabilité a été corrigée dans cette version. Ils le font. (GitHub)

Les détails du correctif dans le commit et la pull request rendent la correction plus concrète. Axios a ajouté une aide à la validation des valeurs d'en-tête, a rejeté les CRLF dans n'importe quelle valeur d'en-tête, a appliqué cette vérification aux valeurs de tableau ainsi qu'aux valeurs individuelles, et a appliqué la validation dans les chemins de définition des en-têtes. Le résumé de la demande d'extraction est particulièrement utile car il précise le changement de comportement : les en-têtes contenant CR ou LF sont rejetés avec "Invalid character in header content," et la couverture de la régression a été ajoutée pour l'adaptateur du navigateur, le logiciel Node rechercher l'adaptateur Node http adaptateur, et En-têtes Axios. C'est le type de correctif que l'on souhaite voir pour ce type de problème, car il réduit l'ambiguïté à la limite de la bibliothèque au lieu de la laisser au comportement en aval. (GitHub)

Le correctif en dit également long sur la philosophie de la sécurité. Avant la correction, même si un moteur d'exécution en aval était susceptible de rejeter les valeurs d'en-tête malformées, Axios était toujours prêt à porter ces valeurs suffisamment loin pour qu'un avis publié puisse présenter la bibliothèque comme un gadget dans une chaîne plus large. Après la correction, Axios rend ce type d'état d'en-tête non sécurisé invalide beaucoup plus tôt. En termes pratiques, cela rapproche le point de défaillance de l'application et facilite grandement les tests. Il est beaucoup plus facile de raisonner sur une requête rejetée dans la bibliothèque du client que sur une défaillance propre à l'exécution et située plus loin dans la pile. (GitHub)

Le fait que la version 1.15.0 corrige également CVE-2025-62718 est une autre raison de ne pas faire preuve d'ingéniosité dans les mises à jour partielles. La note de mise à jour indique que la correction de la gestion du proxy ferme une NO_PROXY un contournement de la normalisation des noms d'hôtes qui pourrait conduire à un SSRF. La description de la CVE-2025-62718 par NVD indique qu'Axios n'a pas réussi à normaliser les noms d'hôtes tels que localhost. ou [::1] correctement contre NO_PROXYIl s'agit d'un bogue distinct, mais il se situe dans le même vaste domaine : les limites de confiance sortantes, les hypothèses de SSRF et les demandes allant là où l'opérateur ne voulait pas qu'elles aillent. Il s'agit d'un bogue distinct, mais il se situe sur le même territoire : les limites de confiance sortantes, les hypothèses SSRF et les requêtes allant là où l'opérateur ne voulait pas qu'elles aillent. Si vous utilisez déjà Axios, passez directement à la version qui corrige les deux. (GitHub)

Voici le type de test unitaire post-mise à niveau qui vaut la peine d'être ajouté à votre propre suite, même si vous n'essayez jamais de reproduire la chaîne d'avis complète :

import axios from "axios" ;

test("rejette les CRLF dans les valeurs d'en-tête sortantes", async () => {
  await expect(
    axios.get("http://127.0.0.1:3000/health", {
      headers : {
        "x-test" : "safe\r\nInjected : yes"
      },
      timeout : 1000
    })
  ).rejects.toThrow(/Invalid character/i) ;
}) ;

Il ne s'agit pas d'un test d'exploit. Il s'agit d'un test de limite. Il affirme que votre chemin de requête échoue maintenant là où il devrait échouer. Le résumé de la RP d'Axios indique que ce rejet du "contenu d'en-tête non valide" est exactement le comportement que le correctif est censé imposer. (GitHub)

Qui doit traiter CVE-2026-40175 comme urgent ?

Le groupe le plus prioritaire est celui des applications Node côté serveur qui utilisent Axios pour accéder à des services internes, à des points de terminaison de métadonnées, à des plans de contrôle ou à des API privilégiées. Le principal impact de l'avis est orienté vers le serveur et le nuage, et non vers le navigateur et l'interface utilisateur. Si votre charge de travail se trouve sur EC2 ou un environnement équivalent où l'accès aux métadonnées est important, et si les appels Axios sont utilisés pour la communication de services internes ou l'accessibilité au plan d'administration, ce CVE devrait être en tête de votre liste de remédiation des dépendances. (GitHub)

Le groupe suivant est constitué d'équipes ayant des antécédents d'exposition à la pollution par les prototypes, ou des modèles de code qui rendent la pollution plus susceptible d'avoir de l'importance. MDN et OWASP soulignent tous deux que la pollution par prototype devient dangereuse lorsque les propriétés polluées sont ensuite consommées comme s'il s'agissait d'un état d'objet ordinaire. Cela signifie que les projets qui utilisent encore beaucoup d'objets ordinaires pour la configuration, les en-têtes, les drapeaux, les cibles de fusion ou les sacs d'options dynamiques méritent plus d'attention que les bases de code qui isolent déjà cet état avec des objets de prototype nul, Carteou des vérifications strictes de la propriété. En d'autres termes, la même version d'Axios peut représenter un risque pratique très différent dans deux bases de code différentes. (MDN Web Docs)

Les équipes qui utilisent Axios entièrement dans le code côté navigateur devraient quand même appliquer des correctifs, mais elles devraient raisonner différemment en ce qui concerne l'impact. La principale voie de compromission dans le nuage dépend de la position du réseau côté serveur et de l'accès aux métadonnées de l'instance. Cette histoire spécifique ne s'inscrit pas clairement dans le modèle d'exécution typique d'un navigateur. Ce qui compte encore dans le contexte des navigateurs, c'est qu'Axios a choisi de rejeter les valeurs d'en-tête CRLF invalides dans les adaptateurs et a ajouté des tests de régression liés aux navigateurs, ce qui signifie que la correction n'est pas "réservée au serveur". L'attitude responsable consiste toujours à mettre à jour, mais sans supposer que toutes les affirmations sensationnelles sur l'impact côté serveur s'appliquent également au navigateur. (GitHub)

Une façon simple d'établir des priorités :

Environnement	Pourquoi c'est important pour CVE-2026-40175	Priorité
Services de nœuds sur des instances en nuage	Accessibilité potentielle des métadonnées et trafic privilégié entre services	Le plus élevé
Passerelles API, travailleurs, microservices internes	Construction lourde de demandes sortantes et hypothèses de confiance interne	Haut
Applications présentant un risque connu d'analyseur syntaxique ou de fusion	Un prototype de pollution ailleurs peut devenir le point d'entrée	Haut
Frontaux réservés aux navigateurs	La fixation est toujours importante, mais l'impact sur les métadonnées dans le nuage est moins direct	Moyen
Code mort ou anciens artefacts de compilation épinglés	Il s'agit toujours d'un correctif, mais l'urgence dépend de l'accessibilité en cours d'exécution.	Au cas par cas

L'intérêt d'un tel tableau n'est pas de dévaloriser la question. Il s'agit d'arrêter de perdre du temps sur un faux binaire où les seules options sont "RCE trivial partout" ou "rien du tout". Cet enregistrement se situe entre les deux. Pour le mauvais environnement, il est dangereux. Pour un environnement moyen, il mérite un correctif rapide et une validation rapide. (GitHub)

Comment trouver l'exposition à Axios dans une base de code réelle ?

Commencez par l'inventaire des versions, mais ne vous arrêtez pas là. Dans les écosystèmes JavaScript, la dépendance directe que vous vous souvenez avoir ajoutée n'est souvent pas la version qui compte réellement dans le graphe déployé. Les fichiers de verrouillage, les dépendances transitives, les images de base et les gestionnaires de paquets au niveau de l'espace de travail ont tous leur importance. La première passe la plus rapide est toujours la bonne vieille passe :

npm ls axios
yarn pourquoi axios
pnpm pourquoi axios

Cela vous indique où Axios est présent et si vous avez affaire à une dépendance directe ou transitive. Cela ne vous dira pas si une image de conteneur ou un pipeline de construction intègre encore une ancienne copie ailleurs, mais cela vous donne le graphe de dépendance immédiat à corriger. La raison pour laquelle cela est important est simple : Le Dependabot de GitHub et la logique du graphe de dépendance sont les plus efficaces lorsque le paquetage vulnérable existe dans un manifeste ou un fichier de verrouillage, mais les organisations réelles exécutent également des logiciels à travers des couches d'images, des contextes de construction en cache et des limites monorepo que le simple balayage du manifeste ne peut pas entièrement capturer. (Docs GitHub)

Si votre environnement comprend des monorepos ou plusieurs lockfiles, cherchez dans le référentiel au lieu de supposer qu'une réponse de premier niveau est suffisante :

find . -name package-lock.json -o -name yarn.lock -o -name pnpm-lock.yaml
grep -R "\"axios\"" .

Examinez ensuite les limites de chaque paquet et la cible de déploiement. L'objectif opérationnel n'est pas seulement de "prouver que le repo dépend d'Axios". L'objectif est de répondre à une question plus stricte : quels artefacts déployés résolvent encore Axios en dessous de la version 1.15.0, et lesquels de ces artefacts peuvent effectuer des requêtes sortantes côté serveur dans un espace réseau sensible. C'est cette deuxième question qui intéresse le CVE. (nvd.nist.gov)

Il convient également de distinguer immédiatement un cas particulier : les versions malveillantes d'Axios du 31 mars ne constituent pas le même incident que CVE-2026-40175. Le post-mortem officiel d'Axios indique que les versions 1.14.1 et 0.30.4 ont été publiées de manière malveillante par l'intermédiaire d'un compte compromis, qu'elles sont restées en ligne pendant environ trois heures et qu'elles doivent être traitées comme une compromission de machine si elles ont été installées pendant cette période. Le post-mortem fournit même un modèle de grep pour le fichier de verrouillage et des étapes de remédiation telles que la rotation des secrets et la vérification de la présence de plain-crypto-js. Cela mérite son propre point de la liste de contrôle, car une équipe qui dit "nous avons mis à niveau vers la version 1.15.0" peut encore manquer le fait qu'un programme d'exécution CI ou un poste de travail de développeur a précédemment installé l'une des versions malveillantes. (GitHub)

Voici une note de triage utile pour les tickets internes :

grep -E "axios@(1\.14\.1|0\.30\.4)|plain-crypto-js" package-lock.json yarn.lock 2>/dev/null

Cette commande est directement issue du post-mortem officiel et vaut la peine d'être exécutée partout où vous soupçonnez que de nouvelles installations ont eu lieu pendant la fenêtre affectée. Gardez-la séparée du ticket CVE pour que la propriété reste claire. Un élément est une vulnérabilité de dépendance. L'autre est une réponse à la compromission de la chaîne d'approvisionnement. (GitHub)

Une fois l'inventaire des versions effectué, ajoutez un petit passage de revue de code ciblé sur la propriété de la configuration des requêtes. Recherchez les wrappers qui fusionnent des options provenant de plusieurs sources, les objets d'aide qui accumulent des en-têtes au fil du temps, et toute utilisation de l'itération d'objets simples sur des entrées potentiellement non fiables. C'est là que le CVE devient réel ou reste théorique. Un projet qui n'utilise jamais de propriétés héritées dans la configuration des requêtes est dans une bien meilleure position qu'un projet qui mélange constamment des objets en forme d'utilisateur dans les options des requêtes. Les conseils de MDN sur la pollution par les prototypes sont particulièrement pertinents ici : prefer Object.keys() plus pour... enVérifier la propriété auprès de Object.hasOwn()et utiliser des objets de prototype nul lorsque des objets d'options sont inévitables. (MDN Web Docs)

Comment patcher Axios en toute sécurité avec npm, Yarn et pnpm ?

Si Axios est une dépendance directe, le chemin du correctif est le plus simple :

npm install axios@^1.15.0
# ou
yarn add axios@^1.15.0
# ou
pnpm add axios@^1.15.0

Les cas les plus difficiles sont ceux où Axios est transitif et où la dépendance directe n'a pas encore été mise à jour. C'est là que les fonctionnalités de remplacement du gestionnaire de paquets cessent d'être une commodité et deviennent un contrôle de sécurité. Les documents officiels de npm indiquent que la fonction dérogations existe spécifiquement pour remplacer les versions dans l'arbre des dépendances, y compris lorsqu'une dépendance d'une dépendance a un problème de sécurité connu. Le champ résolutions est explicitement documentée comme un moyen d'épingler des sous-dépendances lorsque vous ne voulez pas attendre que la dépendance directe publie une nouvelle version minimale. pnpm fournit une fonction dérogations à la racine du projet pour la même raison. (docs.npmjs.com)

Pour npm, une levée forcée à court terme ressemble à ceci :

{
  "overrides" : {
    "axios" : "1.15.0"
  }
}

Pour Yarn Classic, le modèle équivalent est le suivant :

{
  "résolutions" : {
    "**/axios" : "1.15.0"
  }
}

Pour pnpm, placez l'override à la racine de l'espace de travail :

les dérogations :
  axios : 1.15.0

Il ne s'agit pas de solutions définitives. Il s'agit de contrôles provisoires qui vous permettent de réduire les risques plus rapidement que le mainteneur en amont le plus lent. Une fois la dépendance directe rattrapée, retirez la goupille d'urgence et revenez à un chemin de mise à jour normal. (docs.npmjs.com)

Apporter un correctif une fois n'est pas suffisant si la même classe de régression peut tranquillement revenir dans l'arbre la semaine suivante. C'est là que les contrôles de la chaîne d'approvisionnement de GitHub sont utiles. La documentation de GitHub indique que les mises à jour de sécurité de Dependabot peuvent automatiquement ouvrir des demandes de téléchargement pour mettre à jour les dépendances vulnérables vers la version minimale corrigée qui résout l'alerte, et que la fonctionnalité fonctionne à partir du graphe de dépendances et des fichiers de verrouillage du dépôt. L'action d'examen des dépendances peut également faire échouer les demandes d'extraction qui introduisent des dépendances vulnérables connues, et la documentation de GitHub montre exactement comment configurer l'action d'examen des dépendances. échec sur toute la ligne dans un flux de travail. (Docs GitHub)

Un flux de travail minimal qu'il convient de maintenir en place après cet incident ressemble à ce qui suit :

name: Dependency review
on:
  pull_request:
    branches: [ "main" ]

permissions:
  contents: read

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v5
      - name: Dependency Review
        uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: critical

Cet exemple est directement aligné sur la documentation de GitHub. Il ne résoudra pas tous les points aveugles de la chaîne d'approvisionnement, mais il augmente le coût de la réintroduction d'un paquetage critique connu par le biais du flux de demandes d'extraction ordinaire. Pour les écosystèmes où l'adoption des correctifs est à la traîne, cela suffit souvent à transformer un "nous devrions probablement mettre à jour plus tard" en une fusion bloquée. (Docs GitHub)

Il y a également une deuxième leçon de CI cachée dans les propres notes de publication d'Axios et dans l'analyse rétrospective. Après la compromission du 31 mars, les notes de publication de la version 1.15.0 d'Axios indiquent que le projet a renforcé les permissions de CI, épinglé les versions d'action, ajouté les éléments suivants zizmoret la publication de npm avec OIDC et protection de l'environnement. Cela ne fait pas directement partie de CVE-2026-40175, mais c'est une leçon plus générale : le risque de dépendance ne s'arrête pas aux numéros de version. Le chemin par lequel les paquets sont publiés, révisés et consommés est également important. Si votre organisation considère encore les mises à jour des dépendances comme un exercice d'hygiène trimestriel plutôt que comme un plan de contrôle activement appliqué, Axios vient de vous donner plusieurs raisons de revoir cette position. (GitHub)

Comment se prémunir contre la pollution des prototypes après CVE-2026-40175

L'application d'un correctif à Axios ferme la frontière de la bibliothèque publiée. Il ne supprime pas les conditions de pollution qui ont rendu Axios utile en tant que gadget en premier lieu. Les conseils de MDN sur la pollution des prototypes sont exceptionnellement pratiques dans ce cas. Il recommande de vérifier la propriété avec Object.hasOwn(), en évitant pour... en lors de l'itération d'objets en forme d'attaquants potentiels, de la création d'objets de prototype nul pour les sacs d'options et de l'utilisation de l'option Carte ou Set (jeu de mots) au lieu d'objets ad hoc lorsque cela est possible. Il ne s'agit pas de préférences stylistiques abstraites. Elles réduisent directement le risque que les propriétés héritées influencent silencieusement le comportement de l'application. (MDN Web Docs)

Pour le code de construction des requêtes, les objets à prototype nul sont particulièrement pertinents. Le MDN indique explicitement que les objets à prototype nul évitent à la fois la pollution de l'environnement __proto__ et les recherches sur le prototype. L'aide-mémoire de l'OWASP fait la même recommandation et indique Objet.create(null) comme modèle de construction sûr lorsque des objets doivent être utilisés. Cela s'applique presque parfaitement aux types d'objets d'option que les développeurs transmettent aux clients HTTP. Si vous construisez des en-têtes ou des options de requête de manière dynamique, la différence entre {} et Objet.create(null) n'est pas cosmétique dans un code qui se soucie de la pollution des prototypes. (MDN Web Docs)

Un modèle de construction de requête plus sûr se présente comme suit :

function buildSafeHeaders(input) {
  const headers = Object.create(null);

  for (const key of Object.keys(input)) {
    const value = input[key];
    if (typeof value !== "string") continue;
    if (/[\r\n]/.test(value)) throw new Error("Invalid header content");
    headers[key] = value;
  }

  return headers;
}

Le but n'est pas que chaque équipe doive écrire exactement cette aide. L'idée est que la construction de requêtes sûres nécessite trois propriétés : l'itération de la clé propre, la validation explicite et l'absence d'héritage du prototype ambiant. C'est l'état d'esprit que CVE-2026-40175 tente d'imposer à nouveau dans la conversation. (MDN Web Docs)

Lorsque les objets n'ont pas la bonne structure, il faut utiliser la bonne structure au lieu d'argumenter avec la chaîne de prototypes. L'OWASP recommande Carte et Set (jeu de mots) parce qu'ils ne résolvent pas les recherches par l'intermédiaire de Object.prototype. MDN va dans le même sens. En pratique, cela convient parfaitement aux drapeaux de configuration, aux modèles d'en-tête, aux listes d'autorisations, aux contrôles de destination et à d'autres états clé-valeur que les ingénieurs ont souvent l'habitude de représenter par des objets simples. A Carte n'est pas seulement plus propre dans certains de ces cas. Elle est structurellement moins vulnérable aux surprises de type prototype. (cheatsheetseries.owasp.org)

Node vous offre également un contrôle de défense en profondeur qui vaut la peine d'être connu, même s'il ne s'agit pas d'une réponse complète. L'aide-mémoire de l'OWASP indique que Node peut supprimer __proto__ en utilisant le --disable-proto=delete drapeau. L'aide-mémoire indique clairement qu'il ne s'agit pas d'une solution complète, car la pollution peut toujours se produire par le biais des éléments suivants constructor.prototypeIl ne s'agit pas d'un simple contrôle, mais il réduit la surface d'attaque et peut empêcher certaines catégories de chaînes d'exploitation de se comporter comme elles le feraient dans des environnements par défaut. C'est le type de contrôle qui appartient aux environnements d'exécution de production renforcés et à la conversation avec l'ingénierie de plateforme, et non pas comme un substitut aux correctifs ou à l'examen du code. (cheatsheetseries.owasp.org)

L'autre moitié du renforcement est la réalité au niveau du réseau. La documentation IMDSv2 d'AWS rappelle que l'accès aux métadonnées n'est encore qu'un chemin HTTP du point de vue de la charge de travail. Si le processus n'a pas besoin de métadonnées, traitez l'accès aux métadonnées comme un chemin HTTP. 169.254.169.254 comme un privilège à supprimer, et non comme un défaut à tolérer. Gardez IMDSv2 obligatoire là où c'est applicable, gardez la limite de saut serrée sauf si vous avez une raison documentée de l'augmenter, et évitez de normaliser l'idée que chaque charge de travail devrait être capable de parler aux métadonnées pour toujours juste parce que c'est la valeur par défaut au premier jour. L'avis d'Axios est un rappel en bibliothèque d'une vérité du nuage que les défenseurs connaissent déjà : les services de la plateforme interne sont toujours une surface d'attaque lorsque le code de l'application peut les atteindre. (Documentation AWS)

Il y a là aussi une leçon à tirer en matière de reporting. Les documents publics de Penligent sur les rapports de pentest d'IA soulèvent un point qui est directement pertinent pour ce type de validation CVE : un résultat de sécurité digne de confiance n'est pas de la prose polie, c'est une chaîne de preuves reproductible qu'un autre humain peut retester. C'est exactement la bonne norme pour CVE-2026-40175. Vous n'avez pas besoin d'un beau PDF indiquant "compromis critique dans le nuage". Vous avez besoin d'un enregistrement indiquant quelles versions étaient présentes, quel moteur d'exécution a rejeté quoi, quels chemins de sortie étaient accessibles, quels contrôles ont bloqué l'accès aux métadonnées, et ce qui a changé après la correction. C'est une meilleure utilisation de l'automatisation de la sécurité que de transformer les titres en titres plus longs. (penligent.ai)

Comment vérifier le correctif au lieu de simplement mettre à jour la version ?

Un saut de version est une affirmation. La vérification est une preuve. Après une mise à jour vers Axios 1.15.0 ou une version ultérieure, vous voulez prouver quatre choses. Premièrement, le graphe de dépendance ne résout plus une version vulnérable d'Axios. Deuxièmement, les valeurs d'en-tête invalides contenant des CRLF sont rejetées dans votre chemin de requête réel. Troisièmement, les propriétés héritées polluées ne deviennent pas silencieusement des configurations de requête. Quatrièmement, l'application ne peut pas atteindre des destinations internes privilégiées d'une manière que vous n'avez pas prévue. Il s'agit de quatre contrôles différents, et tous ont plus d'importance qu'une capture d'écran d'une alerte de dépendance devenant verte. (nvd.nist.gov)

Commencez par les tests négatifs les plus simples. Ajoutez un test au niveau de la requête qui affirme qu'Axios ne prend pas en compte les CRLF dans les valeurs d'en-tête. Le résumé du PR indique que c'est maintenant le comportement attendu pour tous les adaptateurs. Si votre propre wrapper avale l'erreur, la transforme ou réessaie bizarrement, c'est aussi une information utile. Cela signifie que le plan de contrôle de votre application autour d'Axios a encore besoin d'attention même si la frontière de la bibliothèque est fixée. (GitHub)

Testez ensuite explicitement les limites de propriété. La même page du MDN qui explique la pollution des prototypes recommande également Object.hasOwn() vérifie et met en garde contre pour... en sur les objets en forme d'attaquant. Utilisez ce conseil pour écrire un ou deux tests de régression bon marché autour de n'importe quelle aide dans votre base de code qui assemble des en-têtes ou des options sortantes. Si votre assistant traite toujours les valeurs héritées comme de la configuration ordinaire, le test devrait échouer jusqu'à ce que vous le corrigiez. C'est le genre de régressions qu'une simple mise à jour des dépendances ne peut pas détecter. (MDN Web Docs)

Un simple test de bon sens pour votre propre couche d'aide peut ressembler à ceci :

test("does not inherit polluted header keys", () => {
  Object.prototype.evil = "x";
  const opts = Object.create(null);
  opts["x-safe"] = "1";

  const seen = [];
  for (const key of Object.keys(opts)) {
    seen.push(key);
  }

  expect(seen).toEqual(["x-safe"]);
  delete Object.prototype.evil;
});

Ce test est délibérément ennuyeux. Les bons tests limites le sont généralement. L'objectif est de faire en sorte qu'il soit impossible pour l'état hérité de se faufiler à nouveau dans les classes exactes d'objets qu'Axios consomme par la suite. (MDN Web Docs)

Ensuite, vérifiez les limites du réseau. Si votre charge de travail n'a aucune raison de lire les métadonnées EC2 au moment de l'exécution, faites en sorte que cela soit vrai dans la pratique plutôt que dans une politique. AWS documente l'exigence de jeton, la propriété de jeton spécifique à l'instance, le comportement de la limite de saut et le rejet de la propriété de jeton spécifique à l'instance. PUT demande de portage X-Forwarded-For. Ces détails sur la plate-forme vous donnent des points de test négatifs utiles. Votre régression n'a pas besoin de recréer la chaîne complète de l'avis. Elle doit seulement confirmer que votre application ne peut pas compléter un chemin d'accès aux métadonnées qu'elle n'aurait jamais dû avoir en premier lieu. (Documentation AWS)

Enfin, enregistrer le résultat de manière à ce qu'un autre ingénieur puisse refaire le test. C'est là que l'automatisation peut aider si elle est disciplinée. Le matériel de rapport de pentest d'IA de Penligent a raison d'insister sur la portée, la reproductibilité, les artefacts, les conditions d'exploitation et la preuve claire de la remédiation. C'est la barre que vous voulez ici. Une bonne note de validation interne pour CVE-2026-40175 devrait indiquer exactement quelle image ou quel paquet a été mis à niveau, quels tests négatifs ont été effectués, quelles hypothèses de réseau ont été vérifiées, ce qui est resté hors du champ d'application et quel suivi a été requis pour le renforcement de la pollution du prototype en amont. Le travail de sécurité devient coûteux lorsque chaque nouveau test part de la mémoire au lieu de la preuve. (penligent.ai)

Pourquoi CVE-2025-62718 et la compromission d'Axios du 31 mars doivent-ils être traités dans la même fenêtre de triage ?

Les équipes ont des problèmes lorsqu'elles traitent des événements liés comme des tickets non liés parce que les bogues ont des numéros différents. Axios v1.15.0 n'a pas seulement corrigé CVE-2026-40175. Il a également corrigé CVE-2025-62718, une faille critique. NO_PROXY un contournement de la normalisation du nom d'hôte qui pourrait conduire à un SSRF en envoyant du trafic à travers un proxy configuré alors que les développeurs s'attendaient à ce que le loopback ou le trafic interne le contourne. Il ne s'agit pas du même mécanisme que la chaîne d'injection d'en-têtes, mais le thème est suffisamment proche pour être important : les hypothèses de confiance des requêtes sortantes étaient erronées, et ces hypothèses erronées pouvaient avoir un impact sur la sécurité. (GitHub)

Il y a ensuite le problème de la chaîne d'approvisionnement. Selon l'analyse officielle d'Axios, les versions malveillantes 1.14.1 et 0.30.4 ont ajouté plain-crypto-jsLe CVE, qui a installé un RAT sur macOS, Windows et Linux, a été actif pendant environ trois heures avant d'être supprimé. Cet incident est différent d'un CVE d'un point de vue opérationnel, mais il arrive dans la boîte de réception de la même équipe, sur le même nom de paquet, presque au même moment. Une réponse mature regroupe donc le travail en tant que " réponse à un événement de sécurité Axios " tout en gardant les pistes de remédiation séparées : réponse à la compromission pour les versions malveillantes, mise à niveau des dépendances pour les CVE, validation de l'exécution et de l'accessibilité au réseau, et durcissement de l'IC pour une prévention future. (GitHub)

Ce cadre plus large est également la raison pour laquelle l'article de Penligent sur Axios a raison sur un point : le problème récurrent est la limite de confiance sortante. Certains problèmes d'Axios concernent la destination des requêtes. D'autres concernent la formation des en-têtes. D'autres concernent les règles de proxy. D'autres encore concernent l'intégrité des versions. Mais ils touchent tous à la même question stratégique : lorsque votre code émet une requête, quelles hypothèses cachées faites-vous sur qui l'a façonnée, où elle peut voyager, et quels systèmes privilégiés lui feront confiance une fois qu'elle aura quitté le processus. Il s'agit là d'un modèle mental bien plus utile que de traiter chaque avis comme un météore isolé. (penligent.ai)

Dernières réflexions sur CVE-2026-40175

La CVE-2026-40175 mérite un correctif rapide, mais elle mérite également une conversation plus intelligente que la plupart des gros titres ne lui accordent. L'histoire publique ayant le plus grand impact, la pollution de prototype devenant l'injection d'en-tête devenant SSRF devenant l'abus IMDSv2 devenant la compromission du nuage, est suffisamment sérieuse pour justifier l'urgence. En même temps, le dossier public autour de ce CVE est incohérent, l'entrée NVD est toujours en cours d'analyse, et le comportement documenté de validation d'en-tête de Node signifie qu'il ne faut pas confondre "langage d'avis critique" avec "exploitabilité triviale dans chaque déploiement standard". Les deux choses peuvent être vraies en même temps : la classe de bogues est réelle, et la chaîne atteignable dépend de l'environnement. (GitHub)

La réponse technique mature n'est donc pas difficile à décrire. Patch vers la version 1.15.0 ou plus récente. Inventorier chaque graphique déployé, et pas seulement le paquet que vous vous souvenez avoir ajouté. Séparer la réponse à la publication malveillante du 31 mars de la réponse au CVE. Examiner le code de construction des requêtes pour détecter les états hérités et les faiblesses dans la gestion des objets. Garder l'IMDS et les plans de contrôle internes hors de portée là où ils ne sont pas nécessaires. Ajoutez des contrôles de CI afin que la même catégorie de problème ne puisse pas revenir discrètement par le biais d'une autre mise à jour transitive. Et, surtout, vérifiez le contrôle dans votre exécution au lieu de confier votre jugement à un score. (GitHub)

La vraie leçon de CVE-2026-40175 n'est pas qu'Axios s'est soudainement transformé en RCE magique. La véritable leçon est que les limites de confiance sortantes font partie de la surface d'attaque, et que l'état hérité en JavaScript peut tranquillement reprogrammer ces limites lorsque les équipes considèrent "juste un objet d'options" comme sûr par défaut. C'est le genre de leçon qui vaut la peine d'être retenue après la fermeture de l'alerte de dépendance. (GitHub)

Lecture complémentaire pour CVE-2026-40175

Sources externes faisant autorité

• Avis GitHub pour CVE-2026-40175, chaîne d'injection d'en-tête Axios et description de l'impact publié. (GitHub)
• Entrée NVD pour CVE-2026-40175, incluant des références au patch commit, à la pull request, et à la page de publication. (nvd.nist.gov)
• La note de mise à jour d'Axios v1.15.0, qui liste la correction de l'injection d'en-tête et le compagnon NO_PROXY fixer. (GitHub)
• Demande de correction d'Axios et résumé du correctif, montrant le rejet des CRLF à travers les adaptateurs et les tests. (GitHub)
• La documentation AWS IMDSv2, pour le flux de jetons et les exigences de demande qui rendent significative l'histoire de l'impact de l'avis sur le nuage. (Documentation AWS)
• Documentation HTTP de Node.js, pour la validation automatique des en-têtes et la gestion des données. ERR_INVALID_CHAR. (nodejs.org)
• Conseils du MDN et de l'OWASP sur la prévention de la pollution des prototypes, y compris Object.hasOwn()les objets à prototype nul, Carte, Set (jeu de mots)et les drapeaux de défense en profondeur des nœuds. (MDN Web Docs)
• Avis GitHub et enregistrement NVD pour le CVE-2025-62718, la NO_PROXY contournement de la normalisation des noms d'hôtes entraînant un risque de SSRF. (GitHub)
• Analyse officielle d'Axios concernant les versions malveillantes de npm du 31 mars 2026. (GitHub)
• Penligent, Axios npm CVE, le vrai risque est votre frontière de confiance sortante. (penligent.ai)
• Penligent, Comment obtenir un rapport de pentest sur l'IA. (penligent.ai)
• Penligent, AI Pentest Tool, ce à quoi ressemble une véritable attaque automatisée en 2026. (penligent.ai)
• Page de présentation du produit Penligent pour les flux de travail automatisés de tests de pénétration. (penligent.ai)