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 était en sommeil, mais n'avait pas atteint sa fin de vie, et sa relance a donné lieu à de nouvelles vulnérabilités CVE concernant des versions dont la version avait été figée depuis longtemps.
- Un même domaine peut contenir plusieurs versions de Lodash, dont la plupart sont intégrées de manière transitive.
- Il est facile de repérer un exemplaire vulnérable ; le plus difficile, c'est de démontrer quel chemin d'exécution y mène.
Personne ne décide, lors d'une réunion de planification, d'adopter Lodash. Ça arrive, tout simplement. Un développeur expérimenté intègre une fonction d'aide, un outil de compilation le répertorie comme dépendance, une bibliothèque de graphiques située trois niveaux plus bas a besoin de _.merge, et tout à coup, elle se retrouve intégrée dans le pack de toutes les applications que vous commercialisez. Une infrastructure discrète, et non un framework choisi par qui que ce soit.
Il est présent partout où un fichier JavaScript s'exécute : code front-end, services back-end, outils de build, interfaces en ligne de commande (CLI), scripts d'automatisation, et même ce package interne abandonné qu'une équipe a écrit en 2019 et que personne n'a plus ouvert depuis. Le rapport 2024 de Sonatype estime à 4 500 milliards le nombre de requêtes de packages pour npm rien que pour cette année-là, et Lodash figure parmi les packages les plus utilisés dans ce flot.
Puis vint un tournant que ni les notes de mise à jour ni la plupart des rétrospectives n’ont relevé. La version 4.17.21 a été publiée en février 2021, et pendant des années, rien n’a suivi. Les équipes ont interprété ce silence comme un signe de stabilité, ont figé la version et sont passées à autre chose.
Cette interprétation était erronée. L'absence d'avis de sécurité n'a jamais constitué une preuve de sécurité. Elle ne disait pas grand-chose sur l'exposition réelle, et cela est apparu clairement dès que le projet relancé a commencé à rattraper son retard en matière de sécurité.
Lodash fait-il encore l'objet d'une maintenance ?
Oui, encore une fois, après une longue période d'inactivité. Lodash est resté pratiquement inactif pendant des années, puis a repris une gestion active en 2025. Les avis de sécurité publiés en 2026 expliquent pourquoi d'anciennes alertes ont commencé à s'afficher.
Lodash a vu le jour en 2012 sous la forme d'un fork d'Underscore, et son créateur est passé par les fondations Dojo et jQuery avant que le projet ne rejoigne l'OpenJS Foundation, où il est actuellement en train de passer au stade de maturité « Feature-Complete ». Son histoire récente est plus facile à suivre sous forme de chronologie.
| Date | Que s'est-il passé ? |
|---|---|
| Février 2021 | La version 4.17.21 apporte des correctifs concernant une vulnérabilité d'injection de commande dans _.template et un problème de ReDoS, puis des années de calme |
| 2025 | OpenJS annonce un financement de la part de Sovereign Tech Agency, une refonte de sa gouvernance et la création d'un nouveau comité de pilotage technique |
| janvier 2026 | 4.17.23 corrige un problème de pollution dans le prototype _.unset et _.omit (CVE-2025-13465), affectant les versions 4.0.0 à 4.17.22 |
| mars 2026 | La version 4.18.0 corrige un _.template injection de code via les clés d'importation (CVE-2026-4800) et un contournement de la mise à jour de janvier _.unset et _.omit correction (CVE-2026-2950) |
| avril 2026 | La version 4.18.1 devient la version actuelle ; elle corrige une régression liée à la compilation modulaire présente dans la version 4.18.0 |
Cette refonte s'est accompagnée de véritables infrastructures opérationnelles : un plan d'intervention en cas d'incident, un modèle de menaces publié, des avis de sécurité sur GitHub, des analyses CodeQL, l'utilisation de Renovate pour la mise à jour des dépendances, un tableau de bord OpenSSF et une infrastructure d'intégration continue (CI) remaniée.
Le saviez-vous ? L'avis de sécurité 4.17.23 a été déposé auprès de l'autorité de numérotation CVE d'OpenJS. Il s'agissait de la première mise à jour de sécurité de Lodash depuis plusieurs années, et ce type de divulgation coordonnée témoigne d'un processus de sécurité efficace, et non d'un processus inactif.
Voici ce qui importe pour tous ceux qui utilisent encore une ancienne version du code. Cette prise en charge renouvelée permet d'assurer la maintenance et la sécurité de la branche de version actuelle. Cela ne signifie pas pour autant que de nouveaux correctifs soient rétroportés vers la version 3.10.1.
Conséquences d'un projet réactivé sur une version épinglée
Le mécanisme est simple et impitoyable. Une nouvelle alerte peut placer un indicateur inchangé dans une plage d'impact nouvellement identifiée, sans que personne ne touche à votre code. Le numéro de version n'a pas changé. En revanche, son profil de risque connu a évolué.
Trois révélations viennent étayer ce point.
Pollution liée aux prototypes dans _.unset et _.omit a été corrigée dans la version 4.17.23. Le CVE-2025-13465 concerne les versions 4.0.0 à 4.17.22 ; ainsi, une version datant de cinq ans, la 4.17.21, se trouve donc parfaitement dans cette plage.
Une faille permettant de contourner ce correctif a été répertoriée sous le numéro CVE-2026-2950. Le correctif de la version 4.17.23 protégeait les segments de chaîne de caractères, mais pas ceux encapsulés dans un tableau, ce qui permettait à la même attaque par suppression de continuer à fonctionner. Lodash 4.17.23 et les versions antérieures sont concernées ; ce problème a été corrigé dans la version 4.18.0.
Injection de code dans _.template via l'importation des noms de clés, CVE-2026-4800, résulte d'un correctif incomplet apporté à l'ancienne vulnérabilité CVE-2021-23337. Le correctif initial validait la variable « option », mais pas les noms des clés d'importation, et ces deux chemins mènent au même Function() sink. Cette vulnérabilité concerne les versions 4.0.0 à 4.17.23 et a été corrigée dans la branche 4.18.
La sélection de la version ne se fait pas automatiquement ici. La version 4.18.0 comportait une régression liée à la compilation modulaire, et npm la marque désormais comme obsolète avec un message indiquant : « Version défectueuse. Veuillez utiliser [email protected] à la place. » Cela renvoie directement les utilisateurs vers une version affectée par les trois CVE mentionnés ci-dessus. La version 4.18.1 est celle qu’il vous faut. Certaines des fonctions uniques lodash.* Les paquets ont également été régénérés sur la nouvelle ligne. lodash.unset affiche désormais la version 4.18.0, tandis que d'autres, comme lodash.merge restent bloqués à la version 4.6.2 de 2019 ; les anciens projets qui intègrent directement ces versions doivent donc les vérifier une par une.
Attention : un résultat « vert » obtenu lors de l'analyse de « lodash 4.17.21 » datant de 2024 ne reste pas vert indéfiniment. En effet, les avis de sécurité publiés en 2026 s'appliquent rétroactivement à cette version précise, et rien dans votre fichier de verrouillage ne vous le signalera tant que vous n'aurez pas relancé l'analyse.
Imaginez une console d'administration Angular datant de 2018, avec Lodash 3.10.1 inclus dans le bundle et lodash.merge attiré par deux bibliothèques de graphiques abandonnées. Le rapport de l'analyse ne présente aucune anomalie, mais ne contient rien non plus qui justifie une action. C'est dans cet écart entre précision et utilité que commence le véritable travail.
La pollution des prototypes a changé la façon dont les équipes perçoivent les bibliothèques d'utilitaires
Une simple fonction d'aide sur les chaînes de caractères qui met le texte en majuscules ne franchit pas cette même barrière de sécurité. En revanche, une fonction qui fusionne des objets ou attribue une valeur à un chemin d'accès le fait, et c'est justement cette différence qui fait toute la différence. La fusion d'objets et l'attribution de valeurs à des chemins d'accès impliquent des écritures dans des structures auxquelles votre code fera confiance par la suite, ce qui constitue une limite _.capitalize ne s'en approche jamais.
Le mode de faillite n'a rien d'exceptionnel. Il suffit de fournir une clé spécialement conçue, telle que __proto__ ou constructor.prototype en un élément de fusion ou de définition de chemin vulnérable, et vous pouvez accéder aux prototypes partagés dont héritent les objets ordinaires, à commencer par Object.prototype. Dans le cas le plus bénin, on aboutit à un déni de service lorsque le code en aval se bloque sur un objet corrompu. À l’extrême, avec un récepteur adapté tel qu’un moteur de modèles ou un Function() Lors d'un appel, la pollution de prototype sert de point d'ancrage à l'exécution de code. Une mise en garde concernant ces avis de sécurité spécifiques à Lodash : le _.unset et _.omit Ces failles permettent de supprimer des propriétés des prototypes partagés plutôt que de les écraser ; leur impact réel se traduit donc par des dysfonctionnements et un déni de service, plutôt que par la chaîne classique menant de la pollution à l'exécution de code (RCE).
La précision est toutefois essentielle. Tous les appels à une fonction concernée ne sont pas exploitables. Le facteur déterminant est de savoir si un attaquant peut influencer l’objet fusionné ou le chemin d’accès à la clé. Si ces deux éléments sont entièrement contrôlés par le développeur et ne peuvent pas être atteints par des entrées non fiables, le risque d’exposition est faible. Si l’un ou l’autre peut être influencé par le corps d’une requête, une chaîne de requête ou un fichier analysé, considérez le chemin d’accès comme potentiellement exploitable jusqu’à ce que vous ayez écarté cette possibilité. C’est cette distinction qui différencie un plan de correction d’une simple liste de CVE vous indiquant que tout est en danger.
Le graphe des dépendances constitue le véritable projet de correction
Il suffit d’un seul scan pour détecter une version vulnérable de Lodash. En revanche, déterminer les mesures à prendre prend beaucoup plus de temps. Le rapport « Snyk State of Open Source Security » de 2022 a révélé qu’une application en cours de développement comporte en moyenne 49 vulnérabilités réparties sur 69 dépendances, et les bibliothèques utilitaires telles que Lodash sont précisément celles qui se trouvent à plusieurs niveaux de profondeur.
Le travail en lui-même est assez concret. Commencez par identifier la dépendance parente qui introduit chaque version de Lodash, puis déterminez si la déduplication est réellement sans risque ou si deux utilisateurs ont bel et bien besoin de versions majeures différentes. Déterminez si les remplacements ou les résolutions constituent une solution viable ou s’il s’agit simplement d’une dette reportée. Testez séparément les copies intégrées et celles côté serveur, car elles se résolvent indépendamment les unes des autres. Partez ensuite à la recherche des versions codées en dur ou copiées manuellement que npm ne peut absolument pas détecter.
Lodash ne comporte aucune dépendance d'exécution propre, son arbre est donc vide. Le problème se présente à l'inverse. Lodash figure comme une feuille dans des milliers d'autres arbres, et c'est là que les copies se multiplient. Pour les versions prises en charge, TuxCare ELS peut remplacer les copies vulnérables, qu'elles soient directes ou transitives, par des versions corrigées, ce qui est justement l'objectif recherché lorsqu'un scanner signale six versions différentes dans un même dépôt.
En première ligne : les équipes peuvent « mettre à jour Lodash », clôturer le ticket, et pourtant échouer à l'analyse suivante. Elles ont mis à jour la dépendance de niveau supérieur tout en laissant intactes trois copies transitives à la version 4.17.15, car une mise à jour directe ne réécrit pas ce qu'un paquet enfant a verrouillé.
Cette suppression mérite une petite précision. Le chaînage optionnel, la syntaxe d'expansion et les méthodes modernes des tableaux ont rendu superflues de nombreuses fonctions d'aide de Lodash. La sémantique de la fusion en profondeur, cloneDeep cas limites, debounce comportement, et le fp Les modules, quant à eux, c'est une autre histoire.
Ce qui nous amène à la décision à prendre. Si Lodash n'est utilisé que dans quelques appels simples, le supprimer est généralement la solution la plus simple. Si _.merge ou _.cloneDeep Si cela touche à la logique financière ou de reporting, considérez cette suppression comme un changement de comportement nécessitant son propre plan de test, car ce type de modification peut passer les tests d'intégration (CI) sans problème, puis entraîner une erreur dans un rapport de fin de mois.
Quatre voies de remédiation
Il n'existe pas de solution unique, et prétendre le contraire ne fait que retarder la mise en œuvre des mesures correctives. Quatre voies offrent des options réalistes, et la plupart des parcs immobiliers en utilisent plusieurs.
| Chemin d'accès | À déguster de préférence lorsque | Coût |
|---|---|---|
| Mettre à jour Lodash directement | Vous êtes responsable de la dépendance directe et les tests couvrent les points d'appel | Faible, à moins qu'il n'y ait une raison pour laquelle rien n'ait été épinglé |
| Remplacer les fonctions par du JavaScript natif | Un petit nombre d'appels de fonction simples (enchaînement, répartition, méthodes de tableau) | Modérée, plus élevée pour la logique de fusion/clonage |
| Mettre à jour le paquet parent | Lodash est installé de manière transitive via une dépendance maintenue | Cela dépend des modifications majeures apportées par le parent |
| Appliquer le correctif et conserver la version existante | Il vous faut une ancienne version bien précise intégrée au graphique | Une migration en cours, mais pas forcée |
C'est dans ce dernier cas de figure qu'un correctif fourni par un éditeur trouve toute sa raison d'être. TuxCare ELS for Libraries prend en charge les versions 1.3.1, 2.4.2, 3.2.0, 3.10.1, 4.5.0, 4.17.4, 4.17.5, 4.17.11, 4.17.15, 4.17.19, 4.17.21 et 4.18.1 ; ainsi, la version que vous ne pouvez pas mettre à jour bénéficie tout de même des mesures de sécurité apportées par le correctif en amont.
Le mécanisme n'a rien de spectaculaire, et c'est justement le but. Il suffit d'ajouter un alias npm dans votre répertoire racine package.json aux côtés de overrides Ainsi, les copies transitives sont remplacées par la version corrigée, ou bien vous exécutez l'outil TuxCare Patcher sur un dépôt contenant plusieurs dépendances couvertes. Voilà la réponse directe au problème des copies transitives.
Conseil d'initié : Déclarer overrides à la racine package.json, car npm ignore les remplacements déclarés au sein des dépendances installées. Orientez-les vers la version corrigée et aliasée afin que npm remplace, dans l'ensemble de l'arborescence des dépendances, toutes les occurrences du nom du paquet vulnérable par son équivalent mis à jour.
Comment TuxCare assure la sécurité des anciennes versions de Lodash
Rétroporter un correctif dans une bibliothèque d'utilitaires vieille de dix ans ne se résume pas à un simple copier-coller, et c'est en l'abordant ainsi que l'on finit par perturber précisément les cas limites sur lesquels reposent les applications. Le processus se déroule en quatre étapes.
Tout d'abord, il convient de vérifier si chaque nouvelle vulnérabilité concerne effectivement une version couverte, plutôt que de partir du principe qu'une plage de versions publiées correspond à une exploitabilité dans toutes les applications. Ensuite, il faut répercuter l'objectif de sécurité sans entraîner de changements comportementaux non liés. Cette prudence est ici plus importante que presque partout ailleurs, car les applications dépendent du comportement de Lodash dans des cas limites, qu'une refactorisation bien intentionnée risquerait de modifier discrètement.
Troisièmement, effectuez des tests de régression tant sur les fonctions communes que sur les chemins spécifiques concernés, afin qu’une correction de la « pollution du prototype » ne modifie pas ce qui _.merge renvoie un objet imbriqué valide. Quatrièmement, signez chaque paquet compilé et publiez les documents SBOM et VEX à chaque version, afin que vos auditeurs disposent d'une traçabilité vérifiable plutôt que d'une simple promesse.
Il s'agit là d'un travail de gestion, et non d'innovation en amont, et cette distinction est délibérée. TuxCare est spécialisée dans la sécurisation et la stabilisation du code de production une fois que les priorités en amont ont évolué, en proposant des correctifs prévisibles et axés sur la compatibilité pour les systèmes destinés à fonctionner pendant des années.
Qui a financé la refonte de Lodash, et pourquoi ce modèle est-il important ?
Lodash est l'exemple le plus parlant d'un modèle qui mérite d'être mis en avant. Le financement accordé par la Sovereign Tech Agency, géré avec le soutien de la Fondation OpenJS, a permis de financer les travaux de gouvernance et de sécurité liés à une bibliothèque dont dépendent des millions de systèmes ; l'article publié par OpenJS mérite d'être lu dans son intégralité.
Ce que ce financement ne permet pas, c'est d'assurer la maintenance indéfinie de la version 3.10.1. Il a renforcé le projet actuel ; il n'a pas engagé les bénévoles à retroporter des correctifs vers une version datant de 2015, et c'est en prétendant le contraire que les responsables de la maintenance finissent par s'épuiser.
Le programme « Ecosystem Sustainability » comble cette lacune sur le plan commercial, une partie des recettes étant reversée aux projets participants. TuxCare est membre « Gold » de la Fondation OpenJS et l'un des prestataires du programme ; il figure aux côtés de HeroDevs et NodeSource sur la page consacrée à la fin de vie de Node.js.
Il convient de le préciser clairement, car cela garantit la transparence pour tous. Un correctif éditeur pour la version 4.17.21 est un correctif éditeur, et non une version en amont, et un bon outillage met en évidence cette provenance au lieu de la dissimuler. Et lorsqu’une copie ne peut absolument pas être mise à jour, ELS pour Lodash fournit les correctifs via npm à la version que vous utilisez réellement, aussi longtemps que vous en avez besoin.
FAQ
Lodash est-il en fin de vie ?
Non. Il est resté inactif pendant des années, mais il fait à nouveau l'objet d'une maintenance active dans le cadre d'OpenJS, avec une refonte de sa gouvernance financée et une version actuelle de la branche 4.18.
La version 4.17.21 est-elle toujours sûre ?
Cela ne concerne pas les vulnérabilités révélées depuis la reprise. Elle se situe dans la plage concernée par trois avis de sécurité : CVE-2025-13465 et CVE-2026-2950 (pollution de prototype dans _.unset et _.omit, y compris un contournement du premier correctif) et CVE-2026-4800 (_.template (injection de code). La mise à jour vers la version 4.18.1 corrige ces trois vulnérabilités, tout comme une version maintenue intégrant les correctifs pour chacune d'entre elles.
Dois-je passer à la version 4.18.1 ?
Pour les projets activement maintenus, oui. La version 4.18.1 est la version actuelle ; elle corrige la régression liée à la compilation modulaire présente dans la version 4.18.0. Si une ancienne version spécifique est intégrée à votre graphe, une version corrigée et maintenue via le service « Endless Lifecycle Support » de TuxCare constitue une alternative.
Ai-je encore besoin de Lodash ?
Souvent, non. La syntaxe native a remplacé bon nombre des fonctions d'aide simples, et structuredClone couvre les cas courants de clonage profond, bien qu'il ignore les prototypes de classes et les métadonnées des propriétés, et qu'il lève une exception pour les valeurs qu'il ne peut pas cloner, y compris les fonctions. La fusion profonde, debounce, et le fp Ce module ne dispose toujours pas d'une alternative concise sur une seule ligne.
Avant de clore le ticket
« Mettre à jour Lodash » ne constitue pas un plan de remédiation tant que toutes les copies accessibles n'ont pas été recensées. Vous pouvez suivre les avis de sécurité actuels concernant chaque version concernée sur le suivi CVE de TuxCare.
