Un prototype pollué peut détourner votre trafic axios. Passez à la version 1.18.0.

Le 1er août, les mainteneurs d'axios ont divulgué CVE-2026-67320, une faiblesse de pollution de prototype dans l'adaptateur HTTP Node.js de la bibliothèque. axios est l'un des paquets les plus installés sur npm, ce qui touche de nombreux backends. En résumé : dans les bonnes conditions, un attaquant capable de polluer Object.prototype peut amener votre serveur à router ses requêtes HTTP sortantes via un proxy qu'il contrôle. Pour les appels http:// en clair, ce proxy peut lire l'en-tête Authorization, les identifiants Basic auth, la méthode, l'URL complète, l'en-tête Host et le corps de la requête, puis renvoyer une réponse de son choix. Le NVD lui a attribué un score de 8,3 (Élevé) sur CVSS 4.0.

Voici le mécanisme, car les détails sont importants. axios renforce sa configuration de requête fusionnée en la construisant sur un objet à prototype null, de sorte que les propriétés héritées ne peuvent pas s'y infiltrer. Mais les intercepteurs de requêtes s'exécutent après cette fusion, et un pattern d'intercepteur très courant, return { ...config } ou Object.assign({}, config), reconvertit discrètement cet objet sécurisé en un objet ordinaire avec Object.prototype dans sa chaîne. L'adaptateur Node lit ensuite config.proxy sur cet objet, parcourt la chaîne de prototypes et trouve ce qu'un attaquant a planté dans Object.prototype.proxy. Le correctif de la version 1.18.0 lit ces valeurs de configuration imbriquées via un accesseur sécurisé qui ignore les propriétés héritées.

Un point honnête à préciser : axios seul ne donne pas cela à un attaquant. Il lui faut un autre bug de pollution de prototype quelque part dans votre application ou votre arbre de dépendances pour définir Object.prototype.proxy au préalable. axios est l'amplificateur, pas le point d'entrée. C'est précisément pour cela qu'il vaut la peine d'être pris au sérieux. Les gadgets de pollution de prototype sont courants dans les codebases JavaScript, et cela transforme une découverte que beaucoup d'équipes écartent comme théorique en extraction de credentials.

Nous observons ce schéma en permanence lors de nos tests d'intrusion et audits de sécurité. Le scanner d'un client signale un problème de pollution de prototype, quelqu'un le classe comme « sans impact réel », et il reste dans le backlog pendant un an. Puis un bug comme celui-ci survient et le théorique devient une ligne droite vers des tokens exposés. La pollution de prototype est rarement l'exploit complet. C'est la primitive qui rend le prochain bug bien plus grave.

L'action immédiate est simple et vous devriez la faire aujourd'hui : mettez axios à jour vers la version 1.18.0, ou 0.33.0 si vous êtes encore sur la branche 0.x. Tout ce qui va de 1.15.2 à 1.18.0, ou de 0.31.1 à 0.33.0, est affecté. Exécutez npm ls axios et cela vous montrera chaque copie dans votre arbre, y compris les dépendances transitives que votre propre code n'a jamais importées. Ce sont ces copies transitives qui posent généralement problème, car personne ne les surveille.

Puis allez un cran plus loin que le correctif. D'après notre travail en PHP et Docker sur des backends cloud-native, les équipes qui gèrent ces divulgations avec sérénité sont celles qui traitent déjà le trafic sortant comme quelque chose à contrôler, et pas seulement le trafic entrant. Quelques mesures qui portent leurs fruits ici :

• Effectuez les appels serveur-à-serveur via https://, systématiquement. Ce bug ne divulgue rien via TLS correctement validé. L'appel interne en clair http:// entre deux services est celui qui vous brûle.
• Restreignez le trafic sortant. Si un service n'a besoin d'atteindre que trois hôtes connus, une liste blanche de sorties ou un proxy que vous gérez vous-même signifie qu'un config.proxy détourné n'a nulle part où aller.
• Évitez les secrets dans les URLs et réduisez la durée de vie de tout ce que vous envoyez dans Authorization sur les sauts internes. Les tokens de courte durée limitent les dégâts en cas de fuite.

Il y a également un angle mobile, et il est facile à manquer. Dans nos projets natifs iOS et Android, l'application elle-même n'utilise pas axios, mais le backend-for-frontend ou la passerelle API derrière elle le fait très souvent. Un token amont exposé peut silencieusement compromettre tous les clients mobiles en aval, et vous ne le verrez pas dans les logs de l'application. Lorsque nous auditons un système mobile, nous traçons le token jusqu'au bout du backend, pas seulement jusqu'au premier saut.

La leçon sous-jacente au CVE est celle qui mérite d'être retenue. Votre arbre de dépendances est une surface d'attaque, et « nous n'utilisons pas cette fonctionnalité » n'est pas la même chose que « ce code ne peut pas s'exécuter ». axios dispose d'un support proxy que vous ne configurerez peut-être jamais, et la vulnérabilité s'y trouvait quand même. Savoir ce qui est réellement installé, et pouvoir appliquer un correctif en une après-midi, est une capacité que vous construisez avant d'en avoir besoin, pas pendant un incident.

Si vous n'êtes pas sûr de ce qui se trouve dans votre arbre de dépendances ou de la façon dont le trafic sortant quitte vos services, parlons-en.