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
- Express 4 est en phase de maintenance depuis avril 2025, et sa fin de vie est prévue à partir d'octobre 2026.
- Seule la dernière version d'une branche principale bénéficie de corrections ; les versions mineures 4.x « épinglées » ne sont donc pas concernées.
- Express 3 a cessé d'être pris en charge en juillet 2015, et aucune correction n'y a été apportée depuis le mois d'août de cette année-là.
- Express 5 nécessite Node.js 18 ou une version ultérieure ; par conséquent, la mise à niveau d'un framework se traduit souvent par une migration du moteur d'exécution.
Express s'est forgé une réputation en en faisant très peu. Un routage minimaliste, un pipeline de middleware et juste assez de conventions pour éviter aux équipes de se disputer au sujet de la structure des dossiers. C'est précisément grâce à cette sobriété que tant de services ont fini par adopter Express sans que personne n'ait pris de décision délibérée en ce sens, et que personne ne revient y jeter un œil une fois que tout fonctionne.
C'est ainsi qu'une API de paiement se retrouve à utiliser Express 4.17.1 sans aucune modification pendant sept ans, jusqu'à ce qu'un outil d'analyse des dépendances la signale. Rien n'a changé dans le code. Ce qui a changé, c'est tout ce qui l'entoure.
La contradiction réside dans deux affirmations. Le site web d’Express indique que la branche 4.x bénéficie toujours d’un support. Votre outil d’analyse des dépendances vous signale quant à lui que le service présente une vulnérabilité. Ces deux affirmations sont correctes en même temps, car le support de la branche 4.x ne signifie pas pour autant que toutes les versions historiques de la branche 4.x bénéficient d’un support.
Ce n’est pas de la négligence. C’est de la longévité. Le rapport DBIR 2026 de Verizon a révélé que l’exploitation des vulnérabilités est désormais le mode d’entrée le plus courant des violations de données, représentant 31 % des accès initiaux, contre 20 % l’année précédente, et devançant pour la première fois en 19 ans d’existence du rapport l’utilisation abusive des identifiants. Le délai médian nécessaire à la remédiation complète est passé de 32 à 43 jours au cours de la même période. Les systèmes vulnérables sont souvent ceux qui fonctionnent suffisamment bien pour que personne ne ressente d’urgence à leur sujet.
Express 4 est-il en fin de vie ?
Réponse courte : non. Express 4 n'est pas en fin de vie (EOL) à la date d'août 2026, et la branche 4.x continue de proposer de nouvelles versions. Pour répondre plus en détail, le compte à rebours a déjà commencé, et la version majeure ne vous indique en rien si la version fixée dans votre fichier de verrouillage bénéficie ou non de correctifs.
Pendant la majeure partie de son existence, Express ne disposait d'aucun calendrier LTS. Cela a changé en mars 2025, lorsque le projet a publié une stratégie LTS tout en faisant de la version 5.1.0 la version par défaut sur npm. Les versions majeures passent désormais par les phases CURRENT, ACTIVE et MAINTENANCE. Express 4 est entré en phase MAINTENANCE le 1er avril 2025, ce qui signifie que seuls les correctifs de sécurité et les corrections de bogues hautement prioritaires seront pris en charge, la fin de vie (EOL) étant prévue au plus tôt le 1er octobre 2026. Le projet qualifie ces dates d’objectifs plutôt que d’engagements et signale la v4 comme un cas particulier susceptible d’être prolongé, mais la direction à suivre ne laisse planer aucun doute.
Par ailleurs, la page officielle consacrée à la prise en charge indique toujours que les versions 4.x et 5.x sont « en cours » sans date de fin, à côté de la version minimale de Node.js et de la date de début de prise en charge pour chaque version majeure. Ces deux documents ne disent pas la même chose, ce qui constitue une réponse délicate à donner à un auditeur qui vous demande quand votre framework cessera d'être pris en charge.
La règle qui compte vraiment tient en une seule ligne, en haut de cette page d’assistance. Seule la dernière version de chaque branche majeure est prise en charge. La page des mises à jour de sécurité détaille ensuite, version par version, quelles vulnérabilités ont été corrigées dans chaque version. Lues conjointement, ces informations révèlent ce que le numéro de version à lui seul ne précise pas : le fait d’utiliser une branche majeure prise en charge n’équivaut pas à utiliser une version prise en charge.
| Version Express | État de l'assistance | Dernière version | Dates clés |
|---|---|---|---|
| Express 3.x | Fin de vie | 3.21.2 | Le support technique a pris fin en juillet 2015, et aucun problème n'a été traité depuis le 1er août 2015. |
| Express 4.x | Maintenance depuis le 1er avril 2025 | 4.22.2 | Sortie prévue le 11 mai 2026 ; fin de vie prévue au plus tôt le 1er octobre 2026 |
| Express 5.x | En service depuis le 31 mars 2025 | 5.2.1 | Version 5.0.0 publiée le 9 septembre 2024 ; la version 5.x est devenue la version par défaut de npm à partir de la version 5.1.0 |
C'est cette distinction qui détermine si une anomalie d'audit est clôturée ou reste ouverte. Le fait que la version 4.x soit encore en service ne vous apprend rien sur la version 4.17.1, car les correctifs sont appliqués à la version 4.x la plus récente plutôt qu'à la version mineure qui a été figée en 2019. Si vous ne pouvez pas indiquer la version exacte dans votre fichier de verrouillage, vous ne savez pas encore si vous bénéficiez d'un support. Renseignez-vous avant de contester les résultats du scanner.
La capsule temporelle du middleware
Express en soi est un framework léger. Ce qui rend un ancien service Express fragile, ce sont tous les éléments qui y ont été ajoutés : analyseurs de corps de message, systèmes de gestion des sessions, stratégies d'authentification, moteurs de modèles et middlewares personnalisés, écrits il y a des années par des personnes qui ont depuis quitté l'entreprise sans rien documenter.
Le simple fait de mettre à jour Express donne l'impression erronée que le problème est résolu. Même après avoir mis à jour le framework et vu l'alerte de niveau supérieur disparaître, un paquet transitif vulnérable peut toujours se trouver un niveau plus bas, sans avoir été modifié.
Express 4 déclare environ 30 dépendances directes, dont qs, body-parser, send, serve-static, path-to-regexp, proxy-addr, et forwarded, avec une arborescence plus étendue en arrière-plan. Personne n’a choisi ces bibliothèques. Elles sont fournies avec Express, et une vulnérabilité dans l’une d’entre elles devient une vulnérabilité dans votre application dès lors que le chemin d’exécution concerné est accessible. Quatre CVE datant de 2024 illustrent ce phénomène.
| CVE | Problème | Accès à Express via | Corrigé dans |
|---|---|---|---|
| 29041 | Redirection ouverte via res.location() et res.redirect() |
Noyau Express | 4.19.2 |
| 43796 | XSS via res.redirect() |
Noyau Express | 4.20.0 |
| 45296 | ReDoS dans « path-to-regexp » | dépendance « path-to-regexp » | 4.20.0 |
| 52798 | Deuxième vulnérabilité ReDoS dans la fonction « path-to-regexp » | dépendance « path-to-regexp » | 4.21.2 |
Le problème, c'est que la version 4.19.2 est justement celle qui a corrigé la vulnérabilité de redirection ouverte, et qu'elle est néanmoins antérieure à toutes les versions qui ont suivi. Une application fonctionnant sous la version 4.19.2 a donc résolu la vulnérabilité CVE-2024-29041, mais présente toujours les vulnérabilités XSS et les deux failles ReDoS liées à l'expression régulière « path-to-regexp », car ces correctifs ont été intégrés plus tard dans la branche 4.x. Il convient également de noter que la redirection ouverte a nécessité trois tentatives : un premier correctif dans la version 4.19.0, une régression corrigée dans la version 4.19.1, et le contournement correctement géré dans la version 4.19.2. Par conséquent, toute version antérieure à la 4.19.2 n'est pas entièrement corrigée pour ce problème.
Avertissement : Avant de procéder au triage, exécutez la commande suivante : npm ls path-to-regexp qs send par rapport à l'arborescence des dépendances fournie par votre application, puis comparez les versions résolues à celles de votre fichier de verrouillage. Une copie fixée de manière transitive, intégrée par une autre dépendance, peut vous exposer à des risques même si Express est à jour.
Il convient toutefois de garder à l’esprit une mise en garde. « Affecté » ne signifie pas « exploité ». Le fait qu’une vulnérabilité soit considérée comme un incident ou comme un simple élément de la liste dépend de la question de savoir si votre application expose réellement le chemin de code vulnérable à des données d’entrée contrôlées par un attaquant.
C'est précisément cette lacune que les correctifs proposés par les éditeurs pour les logiciels libres visent à combler. La couverture offerte par TuxCare pour Express s'étend à l'ensemble des composants pris en charge fournis avec une version couverte, plutôt qu'aux composants de niveau supérieur. express le programme en lui-même, ce qui fait toute la différence entre la correction d'un constat et son report. Une étude menée par Endor Labs estime qu’environ 95 % des vulnérabilités des logiciels libres se trouvent dans les dépendances transitives plutôt que dans celles choisies directement par les développeurs, et qu’un déploiement existant offre rarement la possibilité de basculer simplement vers la branche sur laquelle le correctif a été intégré. TuxCare’s Suivi des vulnérabilités CVE affiche l'état des correctifs par version, ce qui vous permet de savoir de quel côté de cette ligne vous vous situez.
Express 5 intègre Node.js
Ce qui est souvent omis lorsque la « mise à niveau vers Express 5 » est inscrite au budget, c'est qu'Express 5 nécessite Node.js 18 ou une version ultérieure. Une mise à niveau du framework se transforme alors en une migration de l'environnement d'exécution, accompagnée d'une mise à niveau du framework.
Express 5 a également modifié certains comportements sur lesquels les anciennes applications s'appuyaient discrètement. Les promesses rejetées et les erreurs générées par les gestionnaires asynchrones sont désormais automatiquement transmises au middleware de gestion des erreurs. Un ensemble de signatures obsolètes a été supprimé, notamment res.send(body, status) et la chaîne magique « back » dans res.redirect. La mise en correspondance des routes a été transférée vers la version 8 de « path-to-regexp », qui a supprimé les expressions régulières de sous-expressions dans les chaînes de chemin d'accès afin de limiter les risques de ReDoS ; les routes s'appuyant sur ces modèles doivent donc être réécrites.
Imaginez un service interne de gestion des réclamations qui utilise encore une image de conteneur datant de l'époque de Node 14. Passer d'Express 4 à 5, c'est la partie la plus facile. Le plus difficile, c'est de faire évoluer cette image vers une version de Node.js actuellement prise en charge, qui réponde de toute façon aux exigences minimales d'Express 5, sans casser les modules natifs compilés selon l'ancienne ABI.
Le guide de migration d'Express indique clairement qu'une application v4 ne fonctionnera peut-être pas telle quelle sur la v5, et cette mise en perspective est utile. Cela en fait un problème lié à l'exécution et aux tests avant d'être un problème lié au framework.
Conseils d'experts : Avant de mettre à jour Express, exécutez votre suite de tests actuelle sur la version de Node.js que vous prévoyez réellement de déployer. Un test aussi simple que nvm use <target> && npm test mettra en évidence les défaillances des modules natifs et de l'ABI qui n'ont aucun rapport avec Express.
Trois options réalistes et leur coût respectif
Il n'y a pas de réponse universelle à cette question, mais seulement celle qui correspond à votre graphe de dépendances, à votre couverture de test et à votre environnement d'exécution. Trois approches permettent de couvrir la plupart des situations.
Passer à Express 5
C'est l'option à retenir lorsque l'arborescence des dépendances est propre et que les tests d'intégration sont fiables. Mettez à jour le runtime, mettez à jour Express, passez en revue la gestion des erreurs asynchrones et les modèles de routage, puis observez la CI passer au vert. Le changement de framework peut facilement représenter la partie la moins importante du travail.
Restez sur la version 4.x et suivez l'actualité de la dernière version
Cette solution reste envisageable pour les applications qui s'en tiennent au routage conventionnel et aux middlewares courants, même si les marges de manœuvre s'amenuisent. Suivez la dernière version 4.x, actuellement la 4.22.2, et considérez cela comme une procédure de routine plutôt que comme une opération ponctuelle. Ce n'est pas gratuit non plus. Le 1er décembre 2025, Express a déployé une modification du parseur de requêtes sur les deux branches de production, concernant ce qui avait été répertorié sous le numéro CVE-2024-51999. Le CVE a ensuite été rejeté au motif qu’il ne s’agissait pas d’une vulnérabilité, et les versions 4.22.1 et 5.2.1 ont annulé la modification le soir même, environ quatre heures après la publication des versions initiales. Même cela n’a pas suffi à clore le dossier, puisque la version 4.22.2 de mai 2026 a dû rétablir le comportement d’analyse des tableaux pour les clés de requête répétées. Rester à jour implique d’intégrer ces changements. Rester sur une version majeure prise en charge n’est utile que tant que l’on suit l’évolution de la ligne de développement ; dès que l’on se fige sur une ancienne version 4.x, on se retrouve dans la même situation que tout ce qui est bloqué sur la version 4.17.1.
Assistance prolongée pendant la planification de la migration
Il reste donc les cas que les deux premiers ne couvrent pas : un runtime Node.js bloqué, un middleware d’authentification personnalisé ou une migration qui s’étale réellement sur plusieurs trimestres. Une API réglementée dotée d’une couche d’authentification sur mesure et d’un runtime verrouillé peut facilement nécessiter plus d’un ou deux sprints, et se précipiter parce qu’un scanner est passé au rouge, c’est ainsi que surviennent les pannes. TuxCare ELS couvre des versions spécifiques d’Express, notamment les versions 3.4.8, 3.21.2, 4.17.1, 4.18.1, 4.18.2, 4.18.3 et 4.19.2, distribuées sous forme de scoped @els-js des paquets via un registre TuxCare authentifié.
| Chemin d'accès | Le plus adapté | Effort typique |
|---|---|---|
| Passer à Express 5 | Des dépendances propres, des tests fiables | Principalement le passage à Node.js et les tests qui vont de pair |
| Suivre la dernière version 4.x | Routage et middleware standard | La situation perdure, et la marge de manœuvre s'amenuise |
| Assistance prolongée (ELS) | Environnement d'exécution figé, middleware sur mesure | Une solution provisoire pendant la migration |
En bref. Un graphique clair et des tests convaincants plaident en faveur d’Express 5. Le routage classique et les middlewares standard incitent à suivre la dernière version 4.x et à s’y en tenir. Un runtime figé ou une migration s’étalant sur plusieurs trimestres laissent entrevoir un support prolongé planifié plutôt qu’indéfini, ce qui revêt d’autant plus d’importance que la version 4.x est désormais assortie d’une date de fin de vie (EOL) prévue.
Comment TuxCare prend en charge les versions d'Express dont le support a pris fin
La prise en charge prolongée d'une bibliothèque n'est pas un travail très prestigieux, et c'est justement là tout l'intérêt. Elle commence par la surveillance des vulnérabilités sur l'ensemble de la version Express concernée et des composants pris en charge qui l'accompagnent. La première question qui se pose lors de la divulgation d'une nouvelle vulnérabilité est de savoir si celle-ci affecte réellement cette version, ou si elle ne concerne que des chemins de code introduits par la suite.
Lorsqu’un correctif s’impose, l’approche consiste à procéder à un « backport » rigoureux. Il s’agit de reprendre la modification relative à la sécurité issue du correctif en amont, en laissant de côté la refactorisation sans rapport qui l’accompagnait, et d’éviter d’entraîner une mise à niveau du framework que personne n’avait prévue. Le résultat est soumis à des tests de régression par rapport au comportement hérité avant d’être publié sous forme de paquet maintenu, accompagné des données SBOM et VEX. Ces preuves lisibles par machine permettent à une équipe de sécurité de documenter correctement une vulnérabilité au lieu de la repousser au trimestre suivant. Il s’agit d’une spécialisation plutôt que d’un remplacement de l’amont, ce qui implique la maintenance à long terme de branches que le projet a déjà dépassées, avec des tests de compatibilité avant toute publication.
Les équipes chargées de la conformité posent toujours des questions sur les délais ; voici donc les objectifs publiés. Les vulnérabilités élevées et critiques, c'est-à-dire celles dont le score CVSS 7.0 est égal ou supérieur à 7, ont un délai de réponse cible de 14 jours à compter de leur divulgation publique ; les vulnérabilités moyennes, de 60 jours, et les vulnérabilités faibles, de 90 jours. Les versions concernées et les étapes d'installation sont disponibles dans la documentation TuxCare ELS for Express, tandis que le contexte général est présenté dans la section consacrée à la prise en charge de fin de vie (EOL) des bibliothèques.
La place de la durabilité dans OpenJS
Express est un projet « Impact » de la Fondation OpenJS, ce qui revêt une importance particulière car la Fondation offre un cadre officiel pour le soutien commercial des versions archivées, en fin de vie et plus anciennes des projets. Le programme de pérennité de l'écosystème OpenJS, lancé en mai 2024, vise à mettre en relation les prestataires commerciaux avec ces versions ; les partenaires reversent ainsi une partie de leurs revenus d'entreprise aux projets participants.
TuxCare figure parmi les partenaires ESP aux côtés de HeroDevs et NodeSource ; ce programme exige que les partenaires soient membres « Gold » ou « Platinum » de la Fondation. La page consacrée à la fin de vie de Node.js cite ces trois mêmes prestataires, ce qui indique clairement qu’il s’agit d’un modèle bien établi et non d’une improvisation.
Il convient de préciser clairement deux points. Le programme est non exclusif et ouvert à tout prestataire répondant aux critères requis ; il n'empêche pas les responsables de maintenance de publier des correctifs publics pour n'importe quelle version, y compris celles couvertes par un partenaire ESP. Il est également important de savoir que la page d'assistance du projet Express mentionne actuellement HeroDevs comme option commerciale ; il vous appartient donc de vérifier directement auprès du prestataire de votre choix si votre version spécifique est prise en charge.
Retour à la réalité : un correctif de rétroportage fourni par un éditeur peut corriger les vulnérabilités concernées dans la version 4.17.1, mais cela ne fait pas pour autant de la version 4.17.1 une version prise en charge par le projet en amont. Si une exigence de conformité mentionne spécifiquement la prise en charge par le projet en amont, le correctif de l’éditeur répond à une autre question, et il est important de savoir laquelle vous est posée.
Comment évaluer une ancienne application Express
Avant de choisir une option, déterminez clairement où vous en êtes. Commencez par la version exacte d’Express indiquée dans votre fichier de verrouillage plutôt que par la fourchette indiquée dans package.json. Parcourir les dépendances directes et transitives à l'aide de npm ls et les comparer aux avis de sécurité connus. Dresser l'inventaire des intergiciels personnalisés et de tout comportement non documenté sur lequel repose l'application. Déterminer quelle version de Node.js utilise l'application et si cet environnement d'exécution est toujours pris en charge, car cela détermine si Express 5 est même envisageable. Évaluer ensuite l'ensemble de ces éléments en fonction de leur exposition et de leur importance stratégique pour l'entreprise, de sorte que l'API de paiement soit traitée en priorité par rapport à un tableau de bord interne à faible trafic.
Il y a un aspect qui passe facilement inaperçu. Express peut également être présent de manière indirecte via des SDK, des progiciels intermédiaires et d’autres dépendances ; ainsi, des versions que personne n’a choisi d’installer apparaissent tout de même dans le graphique. Une analyse qui ne tient pas compte du statut du cycle de vie et des dépendances indirectes aboutit à une simple liste plutôt qu’à une vue d’ensemble.
Effectuez la mise à niveau selon un calendrier architectural, et non parce qu’une faille de sécurité a imposé un délai. Le support tout au long du cycle de vie a pour but de vous offrir cette marge de manœuvre, en assurant la mise à jour de la version en service pendant que la migration s’effectue selon un calendrier que vous pouvez tester et contrôler.
