Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Lodash 4.17.21 n'est plus la version sûre qu'elle a été considérée comme telle pendant des années, et elle comporte désormais trois failles confirmées — CVE-2025-13465, CVE-2026-2950 et CVE-2026-4800 — qui n'ont été corrigées que dans la version 4.17.23 et la série 4.18.x.
- La difficulté principale liée à la correction réside davantage dans l'aspect organisationnel que technique ; c'est donc en identifiant les véritables points d'appel, en renforçant la sécurité des entrées au niveau de la frontière et en surveillant les tentatives d'exploitation qu'il est possible de gagner du temps lorsqu'une mise à jour immédiate n'est pas envisageable.
- Les correctifs rétroportés via un service tel que l'ELS for Libraries de TuxCare permettent aux équipes de sécuriser la version 4.17.21, dont la fiabilité est avérée, tout en planifiant une migration réfléchie vers la version 4.18.x, plutôt que de se précipiter dans une migration risquée.
Votre équipe est au courant de ces vulnérabilités. Le ticket est ouvert depuis neuf mois. Personne ne s'en est occupé. Nous allons voir pourquoi, et ce qu'il faut faire au lieu d'attendre.
Il existe un type particulier de vulnérabilité qui n'est jamais corrigé. Non pas parce que les ingénieurs sont négligents, ni parce que les équipes de sécurité sont inactives, mais parce que la correction, bien que techniquement possible, s'avère terrifiante sur le plan opérationnel. La version 4.17.21 de lodash est l'exemple par excellence de ce schéma dans les projets JavaScript modernes, et elle est présente depuis des années dans les environnements de production de l'ensemble du secteur.
Cet article n'est pas une analyse détaillée des CVE. Vous pouvez consulter ces informations ailleurs. Il traite plutôt du fossé qui existe entre le fait de savoir que quelque chose ne va pas et celui de pouvoir y remédier – ainsi que des moyens concrets mis en œuvre par les équipes pour surmonter ce fossé sans faire comme s'il n'existait pas.
Comment Lodash 4.17.21 est arrivé jusqu'ici et s'y est maintenu
Lodash est devenu l’un des bibliothèques JavaScript les plus téléchargées de l’histoire, car il apportait une solution à un véritable problème : la bibliothèque standard de JavaScript était limitée, incohérente d’un environnement à l’autre, et la compatibilité entre navigateurs relevait du parcours du combattant. À son apogée, Lodash était utilisé partout, des projets parallèles de start-ups aux plateformes d’entreprises du classement Fortune 500.
Puis, le JavaScript moderne a mûri. Les méthodes natives des tableaux se sont améliorées. ES6 et les versions suivantes ont intégré bon nombre des modèles utilitaires dont Lodash avait été le pionnier. Les nouveaux projets ont commencé à être livrés sans Lodash. Mais les projets existants – en particulier les bases de code volumineuses, développées sur plusieurs années – n’ont pas supprimé Lodash du jour au lendemain. Ils avaient accumulé des milliers d’appels. Leur refactorisation représentait une tâche colossale dont le résultat était incertain.
La version 4.17.21, publiée en février 2021 pour corriger une faille d'injection de commande à haut niveau de gravité dans _.template (CVE-2021-23337) ainsi qu'un problème de déni de service lié aux expressions régulières (CVE-2020-28500), est devenue la version de référence pour une grande partie de l'écosystème. Et elle est restée en place pendant près de cinq ans, sans nouvelle version. Non pas parce que la version 4.17.21 est définitivement sûre : une nouvelle équipe de gouvernance a depuis révélé de nouvelles failles qui l’affectent — une pollution de prototype dans _.unset et _.omit (CVE-2025-13465 et CVE-2026-2950) et un contournement d’injection de code dans _.template (CVE-2026-4800). Les correctifs sont désormais disponibles dans la branche lodash 4.18.x, mais la mise à niveau ou la suppression complète de lodash représente un coût important, et l’analyse coûts-bénéfices ne plaide que rarement en faveur d’une action immédiate.
Le problème de la dépendance transitive
De nombreuses équipes utilisant Lodash 4.17.21 ne le font même pas directement. La vulnérabilité se trouve trois niveaux plus bas, au sein d'une dépendance d'une dépendance d'un framework qu'elles ont installé il y a deux ans. Exécutez npm ls lodash dans un projet Node.js de taille moyenne et vous découvrirez souvent un arbre ramifié de références indirectes. Il se peut même que le code de l'application n'importe jamais Lodash.
Cela rend la question de la responsabilité particulièrement délicate. À qui incombe-t-il de corriger une dépendance transitive qu’aucun membre de l’équipe n’a introduite intentionnellement ? Le service de sécurité estime que cela relève de l’ingénierie. L’ingénierie estime que cela relève de l’équipe responsable du paquet en amont. Cette équipe affirme que, techniquement, la faille n’est pas exploitable dans le contexte de déploiement actuel. Le ticket reste ouvert.
La psychologie de la vulnérabilité connue
La littérature consacrée à la sécurité met largement l'accent sur les menaces inconnues : les failles « zero-day », les nouveaux vecteurs d'attaque, les adversaires qui agissent plus vite que les défenseurs. Mais dans la pratique, une part importante des incidents réels trouve son origine dans des vulnérabilités qui étaient connues, signalées et dont la correction avait été sciemment reportée.
Lors des analyses menées après coup, les ingénieurs reviennent sans cesse sur ce même schéma. Ils étaient au courant du problème, mais n'ont pas obtenu l'autorisation d'intervenir sur une partie du code qui fonctionnait sans problème depuis des années, et personne ne voulait être celui ou celle qui le ferait planter.
Il ne s'agit pas de négligence. C'est une réaction rationnelle face aux incitations organisationnelles. La mise en production de nouvelles fonctionnalités génère une valeur visible. La refonte d'un graphe de dépendances pour corriger une vulnérabilité qui n'a pas encore provoqué d'incident génère une valeur invisible et comporte des risques concrets sous forme de régressions, de retards et de reproches si un dysfonctionnement survient en production.
Il en résulte ce que les professionnels du risque appellent parfois la « tolérance au risque par défaut » : il ne s’agit pas d’une décision délibérée d’accepter le risque, mais d’une succession de reports jusqu’à ce que le risque devienne omniprésent. Les équipes ne le perçoivent plus clairement, car il a toujours été là. Le scanner le signale, le ticket est mis à jour, le sprint se termine, et Lodash 4.17.21 reste en place.
Une petite bibliothèque, une grande surface d'attaque
Lodash donne l'impression d'être une bibliothèque de petite envergure. Il s'agit d'une bibliothèque d'utilitaires. Elle ne traite ni de l'authentification, ni de l'autorisation, ni des communications réseau – autant d'éléments que la plupart des gens associent à un code sensible en matière de sécurité. Cette perception contribue au problème de report.
Mais la surface d'attaque n'est pas une question de fonctionnalité. C'est une question d'exposition. Les fonctions lodash sont appelées tout au long de la logique de l'application, souvent avec des données ayant franchi des frontières de confiance. Les vulnérabilités liées à la « pollution des prototypes » – où un attaquant peut manipuler la chaîne d'héritage des objets JavaScript en fournissant des données spécialement conçues – peuvent affecter le comportement de l'application de manière non évidente et dépendante du contexte.
A _.merge() au cœur d’un utilitaire de gestion de configuration, traitant du JSON fourni par l’utilisateur, ne semble pas dangereux à première vue. Mais c’est précisément le genre d’emplacement d’appel qui, selon la logique applicative environnante, peut contribuer à des contournements du contrôle d’accès, à la falsification de l’état de l’application, voire à des chemins d’exécution de code. L’apparente inoffensivité de cette fonction explique en partie pourquoi elle est dangereuse.
| Vulnérabilité | Méthodes concernées | Exploitabilité / impact | Sévérité |
| Injection de code (CVE-2026-4800) | _.template (options.imports) | Exécution à distance de code arbitraire lors de la compilation des modèles ; correction incomplète de la vulnérabilité CVE-2021-23337 | Élevé (8,1) |
| Problème lié au prototype (CVE-2026-2950) | _.unset, _.omit | Supprime des méthodes des prototypes globaux via des chemins encapsulés dans un tableau ; contourne le correctif de la vulnérabilité CVE-2025-13465 | Moyen (5,3) |
| Problème lié au prototype (CVE-2025-13465) | _.unset, _.omit | Supprime des méthodes des prototypes globaux à l'aide de chemins de chaînes de caractères spécialement conçus ; peut entraîner un déni de service | Moyen (5,3) |
La possibilité d'exploitation dépend fortement du contexte. Une application qui ne transmet jamais de données contrôlées par l'utilisateur aux méthodes concernées n'est, en réalité, pas exposée. Mais combien d'équipes ont répertorié tous les points d'appel dans une base de code volumineuse et peuvent affirmer cela avec certitude ? Dans la plupart des organisations, la réponse honnête est : pas beaucoup.
Les contraintes concrètes qui rendent cela difficile
La réponse qui s'impose – mettre à jour Lodash ou le supprimer – est correcte en théorie, mais difficile à mettre en œuvre dans la pratique. Plus précisément, elle se heurte à trois problèmes structurels récurrents dans les organisations de toutes tailles.
Cycles de publication et exigences de stabilité
De nombreux environnements de production fonctionnent selon des processus de contrôle des changements qui exigent des tests approfondis, la validation par plusieurs parties prenantes et un délai de maturation minimum avant le déploiement. Une mise à jour de dépendance qui déclenche un comportement inattendu dans une suite de tests d’intégration peut retarder le calendrier de mise en production de plusieurs semaines. Dans les environnements réglementés – services financiers, santé, infrastructures critiques –, les obstacles sont encore plus importants. Les améliorations en matière de sécurité suivent le même processus que tout autre changement, entrant ainsi en concurrence pour attirer l’attention et obtenir l’approbation avec des fonctionnalités qui génèrent une valeur commerciale mesurable.
Risque de régression dans les bases de code existantes
Bien que l'API de Lodash 4.x soit restée stable pendant des années, la suppression de Lodash ou son remplacement par des méthodes natives nécessite de passer au crible chaque point d'appel, et même le passage à la nouvelle version 4.18.x peut entraîner de subtils changements de comportement.
Pour un code qui a accumulé des appels à Lodash pendant cinq ans ou plus, ce n’est pas une tâche qui se fait en un week-end. La couverture des tests est souvent inégale : les parties les plus anciennes et celles qui font le plus appel à Lodash sont souvent les moins bien testées, précisément parce qu’elles sont antérieures aux pratiques de test modernes de l’entreprise.
Lacunes en matière de responsabilité et d'organisation
Dans les architectures de microservices et les grandes structures d’ingénierie, les bases de code ont des responsables – mais cette responsabilité est parfois ambiguë pour les services hérités antérieurs aux structures d’équipe actuelles. Un service développé par une équipe qui a depuis été réorganisée peut ne pas avoir de responsable clairement identifié. Le service de sécurité signalera la vulnérabilité. Le service d’exploitation notera le service dans le rapport. Personne n’aura l’autorité ni le contexte nécessaires pour apporter la modification. Ce phénomène est plus courant que la plupart des organisations ne veulent bien l’admettre.
APERÇU STRUCTUREL
La vulnérabilité n'est pas le plus gros problème. Le plus gros problème est d'ordre organisationnel : identifier le responsable, justifier la priorité à accorder à cette tâche, réserver du temps dans un sprint et prendre en compte le risque de régression. La complexité technique ne représente souvent qu'une infime partie du défi.
Ce que font réellement les équipes et ce qui fonctionne
Compte tenu de ces contraintes, les organisations d'ingénierie de pointe ne se contentent pas d'ignorer la version 4.17.21 de Lodash en espérant que tout ira pour le mieux. Elles mettent en œuvre toute une série de stratégies de réduction des risques qui tiennent compte du fait que la mise à niveau ne peut pas se faire immédiatement, tout en limitant les risques dans l'intervalle. Aucune de ces stratégies n'est parfaite, mais toutes valent mieux que rien.
Identification et cartographie de l'exposition
La première étape consiste à procéder à une évaluation honnête. Toutes les applications qui intègrent Lodash dans leur arborescence de dépendances ne sont pas exposées au même risque. Les équipes qui consacrent du temps à recenser les emplacements réels d’appel — en particulier les méthodes liées au risque connu de la version 4.17.21, telles que _.template, _.unsetet _.omit — permettent d’établir un classement réaliste des risques. Un service qui utilise lodash uniquement pour _.isEqual et _.cloneDeep sur des structures de données internes est radicalement différent de celui qui compile _.template à partir d'une entrée contrôlée par l'utilisateur.
Ce travail de cartographie est utile même s'il ne débouche pas immédiatement sur une solution. Il permet de transformer l'inquiétude générale et diffuse concernant Lodash en une liste hiérarchisée des risques réels, ce qui facilite la planification des mesures correctives.
Validation des données d'entrée et renforcement de la sécurité au niveau des limites
Les vulnérabilités de type « pollution de prototype » et « injection de commande » nécessitent généralement une entrée contrôlée par l'attaquant pour atteindre la fonction vulnérable. Renforcer la validation des entrées aux limites de l'application – en imposant une validation de schéma sur les données JSON entrantes, en rejetant les entrées présentant des modèles de clés suspects tels que __proto__ ou constructor, et en nettoyant les chaînes de caractères avant qu’elles n’entrent dans les fonctions de modèle – permet de réduire l’exploitabilité sans toucher à la dépendance sous-jacente.
Il s'agit d'une mesure de compensation, et non d'un correctif. La vulnérabilité persiste. Cependant, limiter les voies par lesquelles les données saisies par un attaquant peuvent atteindre le code vulnérable constitue une solution provisoire défendable, et c'est le genre de modification qui peut souvent être apportée sans nécessiter un cycle de publication complet.
Surveillance et détection
Les outils d'autoprotection des applications en exécution (RASP) et les pare-feu d'applications web peuvent être configurés pour détecter et bloquer les schémas de tentatives de « pollution de prototypes ». La journalisation et les alertes concernant les schémas suspects de clés d'objets dans les requêtes entrantes permettent de déterminer si la vulnérabilité fait l'objet d'essais actifs, même si elle ne peut pas encore être corrigée.
La détection n'élimine pas le risque, mais elle modifie le profil de risque. Une vulnérabilité connue faisant l'objet d'une surveillance active est nettement moins dangereuse que la même vulnérabilité dans un système ne générant aucune alerte. À tout le moins, la détection permet une intervention plus rapide en cas d'exploitation de la vulnérabilité.
Accorder un soutien de manière sélective
Pour les organisations qui gèrent plusieurs applications présentant des dépendances héritées, une approche de plus en plus courante consiste à considérer la prolongation du support comme un outil explicite de gestion des risques. Plutôt que d’imposer une mise à niveau risquée selon un calendrier qui engendre ses propres risques, les équipes peuvent recourir à des services tels que ELS for Libraries de TuxCare pour bénéficier de correctifs de sécurité rétroportés sur des versions spécifiques de bibliothèques, ce qui permet de préserver la stabilité d’une configuration éprouvée tout en appliquant des correctifs aux vulnérabilités les plus critiques.
Il ne s'agit pas d'une solution définitive, et elle ne doit pas être présentée comme telle. L'objectif est de gagner du temps : le temps nécessaire pour planifier et mener à bien une migration en bonne et due forme sans se retrouver à découvert entre-temps. Pour les équipes soumises à un contrôle rigoureux des changements, ou chargées de gérer des services dont les dépendances sont mal comprises, cette approche permet de concilier l'amélioration de la sécurité avec la réalité opérationnelle, plutôt que d'exiger une mise à niveau que l'organisation n'est pas prête à absorber.
Une migration progressive plutôt qu'une refonte radicale
Si l'objectif final est de supprimer complètement Lodash, les approches progressives permettent de réduire les risques liés à la migration elle-même. Remplacer les utilitaires de Lodash méthode par méthode, en commençant par les points d'appel présentant le plus grand risque puis en élargissant progressivement le champ d'action, permet d'éviter une refonte radicale qui a tendance à échouer. Les équipes suivent les progrès grâce à des audits des dépendances, suppriment l'utilisation de Lodash service par service, et considèrent chaque suppression comme une réduction mesurable du risque plutôt que comme une tâche parmi d'autres dans un backlog indifférencié.
La comptabilité honnête
La vérité dérangeante concernant Lodash 4.17.21 n’est pas qu’il soit en production. C’est qu’il restera en production pendant longtemps dans la plupart des organisations, quels que soient les rapports des scanners de sécurité ou le contenu des avis de sécurité. Les ressources techniques sont limitées. La tolérance au risque est un phénomène organisationnel bien réel. Le choix entre « mettre à jour immédiatement » et « gérer prudemment la situation tout en planifiant une véritable migration » continuera, dans de nombreux contextes, à pencher en faveur de cette dernière option.
La réponse à cette réalité n'est pas la résignation. Il s'agit d'une gestion honnête des risques : identifier les points d'appel exposés, renforcer les barrières de sécurité, surveiller les tentatives d'exploitation et, lorsque le délai de mise à jour est réellement long, utiliser les outils disponibles pour réduire la fenêtre de vulnérabilité sans prétendre que le problème sous-jacent est résolu.
La maturité en matière de sécurité ne consiste pas à n'avoir aucune vulnérabilité connue. Il s'agit plutôt d'avoir une bonne visibilité sur les risques, de considérer les reports comme des décisions délibérées plutôt que comme une accumulation invisible, et de combler systématiquement les lacunes. Lodash 4.17.21 constitue un cas test pertinent pour déterminer si une organisation est capable de le faire en toute honnêteté.
Ce ticket est ouvert depuis neuf mois. Il est temps de décider ce que vous comptez réellement en faire.
