Fastify EOL : versions, dates, risques et options (2026)

Principaux enseignements

• La version 3 de Fastify a atteint sa fin de vie le 30 juin 2023, et la version 4 a suivi le 30 juin 2025.
• Seule la branche v5 bénéficie encore de corrections de la part de l'équipe Fastify, tandis que la v6 est déjà entrée en phase alpha.
• Fastify v5 nécessite Node.js 20 ou une version plus récente, et Node 20 arrivera en fin de vie (EOL) en avril 2026 ; la mise à niveau du framework entraîne donc nécessairement celle du runtime.
• Assistance « Endless Lifecycle » de TuxCare couvre les versions 3.29.5 et 4.29.1 de Fastify avec des correctifs CVE continus pendant que vous planifiez la migration.

Si vous effectuez un inventaire sur un parc important de serveurs Node.js, vous constaterez généralement que certains services fonctionnent encore sous Fastify v3, dont la prise en charge à long terme (LTS) a pris fin en juin 2023. Cela représente plus de trois ans sans correctifs de sécurité pour ce framework, alors que le code est toujours en production à l'heure actuelle.

Fastify v4 n'est plus prise en charge non plus, puisque sa période de support à long terme (LTS) a pris fin le 30 juin 2025. Il ne reste donc plus que la v5, publiée en septembre 2024, comme seule version pour laquelle l'équipe principale continue d'apporter des correctifs. Passer à cette version implique également de passer à une version de Node.js encore prise en charge, car Node 20 est désormais en fin de vie (EOL) et Node 22 est déjà en phase de maintenance.

Vous découvrirez ci-dessous ce que signifie réellement la fin de vie (EOL) de Fastify, quels risques sont réels et lesquels sont purement théoriques pour chaque ligne, à quoi ressemble un parc de serveurs v3 lorsque ce ticket de migration ne cesse d'être repoussé d'un trimestre à l'autre, et quelles sont vos trois options réalistes.

Qu'est-ce que Fastify ?

Fastify est un framework web Node.js conçu pour minimiser la charge par requête. Son architecture basée sur des plugins assure l’encapsulation, ce qui empêche les décorateurs d’une route d’interférer avec ceux d’une autre. Il effectue la validation et la sérialisation via JSON Schema et gère la journalisation via pino. Lors de la sortie de la version 5, la Fondation OpenJS a le nombre de téléchargements mensuels à 7,8 millions, avec 296 plugins officiellement reconnus dans l’écosystème. En juillet 2026, selon npm-stat, ce chiffre avait dépassé les 43 millions de téléchargements mensuels.

 

Par rapport aux frameworks que vous avez sans doute déjà utilisés, Express est le plus ancien et de loin le plus répandu : il enregistre environ douze fois plus de téléchargements mensuels sur npm que Fastify, alors qu’il ne propose pratiquement aucune validation intégrée, et c’est le framework d’origine le plus courant parmi les équipes. Hapi nécessite une configuration plus lourde et intègre davantage de fonctionnalités par défaut. Koa est un noyau de middleware minimaliste où presque tout le reste relève d’un choix que vous devez faire séparément. NestJS n’est pas vraiment un concurrent, puisqu’il s’agit d’un framework d’application qui s’exécute soit sur Express, soit sur un adaptateur Fastify.

Si votre service est une application NestJS utilisant l'adaptateur Fastify, Fastify figure dans votre arborescence de dépendances, que l'inventaire des ressources de votre équipe la qualifie ou non d'application Fastify. Il en va de même pour la version de Node.js qui la sous-tend : elle a discrètement atteint sa fin de vie et reste clouée là par un framework que quelqu’un a choisi il y a deux équipes et une réorganisation de cela.

Conseil de pro : exécutez npm ls fastify –all dans chaque dépôt de service, et pas seulement dans ceux où vous pensez qu’il est utilisé. Les adaptateurs, les générateurs et les SDK internes intègrent Fastify en tant que dépendance transitive, et ces copies ont rarement un propriétaire clairement identifié. C'est généralement ainsi qu'apparaît une installation errante de la version 3.

Fastify a-t-il atteint sa fin de vie ?

Les versions v1, v2, v3 et v4 de Fastify ont toutes dépassé leur date de fin de support LTS. La v5 est la seule branche à bénéficier de correctifs actifs de la part de l'équipe principale, et sa mention dans le calendrier officiel indique toujours « À déterminer ». Cela ne restera toutefois pas ainsi indéfiniment. Fastify 6.0.0-alpha.1 a été publié en août 2026, et conformément à cette politique, la version v5 ne bénéficiera plus que de mises à jour de sécurité pendant six mois à compter de la sortie de la version v6.

Ce calendrier n'est pas arbitraire, même s'il peut sembler l'être vu de l'extérieur. La politique LTS de Fastify prévoit pour chaque version majeure un minimum de six mois de support actif, suivis de six mois supplémentaires de mises à jour de sécurité uniquement une fois la version majeure suivante disponible. C’est ce calcul qui fixe la fin du support LTS de la version 4 au 30 juin 2025.

Une fois ce délai écoulé, la politique précise que les responsables continueront à examiner et à publier des correctifs de sécurité, mais uniquement lorsque la communauté les fournira et à condition qu’ils ne se heurtent pas à d’autres contraintes, telles que la version minimale prise en charge de Node.js. Il s’agit donc d’un support conditionnel, assuré par la communauté, plutôt que d’une ligne de versions maintenue. Un bug grave dans la v4 pourrait aujourd’hui faire l’objet d’un correctif communautaire, d’une note polie invitant à effectuer une mise à jour, ou simplement rester ouvert sous forme de ticket GitHub.

C'est en pariant sur l'un de ces trois scénarios pour une API de production que les équipes se retrouvent dans une situation délicate. C'est précisément pour cette raison que le support de sécurité étendu a été mis en place.

Cycle de vie des versions de Fastify et dates clés de fin de vie (EOL)

Ces dates proviennent directement du calendrier LTS publié par Fastify. La colonne « Node.js » reprend les séries de versions qui y sont répertoriées pour chaque version majeure ; c'est pourquoi elle inclut des versions « Current » à durée de vie limitée, telles que les versions 9 et 11, aux côtés des séries LTS.

Version de Fastify	Date de sortie	Fin du support à long terme (LTS)	Situation actuelle	Liste des lignes Node.js
1.0.0	Mars 6, 2018	Septembre 1, 2019	EOL	6, 8, 9, 10, 11
2.0.0	Février 25, 2019	Janvier 31, 2021	EOL	6, 8, 10, 12, 14
3.0.0	Juillet 7, 2020	Juin 30, 2023	EOL	10, 12, 14, 16, 18
4.0.0	Juin 8, 2022	Juin 30, 2025	EOL	14, 16, 18, 20, 22
5.0.0	Septembre 17, 2024	Non annoncé	Actif	20, 22

Une précision concernant la ligne « v5 » : elle indique les versions testées au moment de la sortie de la v5, mais la CI de Fastify sur la branche « main » exécute désormais ses tests unitaires avec Node 24 et 26. Node 20 apparaît également dans cette ligne, mais sa fin de vie (EOL) est prévue le 30 avril 2026 ; il convient donc de le considérer comme un seuil de compatibilité plutôt que comme une version sur laquelle vous pourriez déployer votre application.

Regardez maintenant la ligne « v3 » à côté de la date d'aujourd'hui. Trois ans après la fin du support LTS, sur une plage Node.js (de 10 à 18) qui est elle-même entièrement en fin de vie, et la version v4 étant également obsolète, il ne reste plus aucune étape intermédiaire vers laquelle se tourner. C'est pourquoi « se contenter de mettre à jour » représente un défi bien plus important pour un parc de serveurs en v3 que cela ne le semble pour un parc en v4.

Risques de sécurité liés à l'utilisation de Fastify (en fin de cycle de vie) en production

Le risque ne réside pas dans le fait qu’une faille CVE spécifique se trouve dans votre node_modules . C’est l’asymétrie qui entre en jeu le jour où votre version arrive en fin de vie (EOL) et qui s’aggrave chaque année par la suite. La recherche en sécurité sur Fastify continue à avancer à plein régime, et les correctifs qu’elle produit sont développés pour la branche v5 prise en charge. Pour un parc de serveurs sous v4, cela représente déjà plus d’un an de retard accumulé. Pour un parc sous v3, trois ans.

Les CVE du framework ne concernent plus votre version

La famille de failles liées à la validation du type de contenu illustre parfaitement ce que cela implique concrètement. En avril 2025, le CVE-2025-32442 a signalé une faille par laquelle les applications définissant une validation par type de contenu pouvaient voir cette validation complètement contournée, simplement en envoyant un en-tête Content-Type légèrement modifié. L'avis de sécurité mentionne que les versions Fastify 5.0.0 à 5.3.1 et 4.29.0 sont concernées, les correctifs étant disponibles dans les versions 5.3.2 et 4.29.1. La version v4 a bénéficié d'une version corrigée car elle était encore dans sa période de support, et la version v3 n'a jamais été répertoriée comme concernée. Un an plus tard, cette même famille a donné lieu à la faille CVE-2026-33806, une faille de gravité élevée permettant de contourner ce correctif même en utilisant rien de plus simple qu’un espace en début d’en-tête, corrigée uniquement dans la version 5.8.5.

La mise à jour de sécurité du premier trimestre 2026 de la Fondation OpenJS recense 18 vulnérabilités (CVE) de l'écosystème publiées via ses opérations CNA au cours de ce trimestre, dont trois concernent l'écosystème Fastify. Deux d'entre elles concernaient Fastify lui-même. La faille CVE-2026-3419 était un problème de validation du Content-Type mal formé affectant les versions 5.7.2 à 5.8.0 et corrigé dans la version 5.8.1, ce qui en fait une régression propre à la version 5 plutôt qu’un backport manquant. CVE-2026-3635 est celle qui mérite qu’on s’y attarde : un faille de , dont l’avis de sécurité couvre toutes les versions de Fastify jusqu’à la 5.8.2, le correctif n’étant disponible qu’à partir de la version 5.8.3. Toutes les installations des versions v3 et v4 se trouvent dans cette plage concernée, et aucune d’entre elles n’a reçu de version corrigée.

Le troisième, CVE-2026-2880, était une faille de contournement d'autorisation à haut niveau de gravité dans le module optionnel @fastify/middie , dans lequel les middlewares liés à un chemin d’accès pouvaient être contournés car le plugin normalisait les chemins de requête différemment du routeur. Le correctif est disponible dans la version 9.2.0 de middie, et la branche 9.x est développée pour Fastify v5. La branche 8.x, sur laquelle tournent les applications v4, s’est arrêtée à la version 8.3.3 en septembre 2024 et n’a jamais bénéficié de ce correctif.

Rien de tout cela ne ralentit. OpenJS indique dans sa mise à jour du deuxième trimestre 2026 que son CNA a publié 3 CVE au second semestre 2025 et 49 au premier semestre 2026, avec une dizaine d’autres en attente de publication. Cette hausse s’explique principalement par un triage plus rigoureux et des analyses assistées par IA plutôt que par une vague soudaine de nouveaux bugs, mais l’effet sur une gamme de produits en fin de vie est le même dans les deux cas. Davantage de vulnérabilités divulguées – dont aucune ne concerne votre version.

Le moteur d'exécution sous-jacent dispose de sa propre horloge

Fastify v3 a été testé avec les versions 10 à 18 de Node.js, qui sont toutes désormais en fin de vie (EOL). Les équipes restent sur l’ancienne version de Fastify car la mise à niveau est coûteuse, et la même pression budgétaire qui les retient là les oblige généralement à rester sur une ancienne version de Node.js également. Pour un service v3, cela correspond souvent à deux versions dont la prise en charge a pris fin il y a des années, et c’est le runtime qui expose la plus grande surface d’attaque, depuis le TLS et l’analyse HTTP jusqu’à la mise en réseau et tout ce qui se trouve en dessous du code de votre application.

C’est là la véritable raison pour laquelle les équipes se retrouvent dans une impasse, et cela tient rarement au framework lui-même. Personne ne définit la « mise à niveau du framework web » comme une migration à chaud, associée à un changement d’image de base et à une recompilation des modules natifs. Puis quelqu’un le fait, l’estimation triple, et le ticket est repoussé au trimestre suivant.

Quand les contraintes de dépendance vous mettent au pied du mur

L'arborescence de Fastify est véritablement allégée, et il convient de le reconnaître en toute honnêteté. À partir de la version 5.12.0 de Fastify, l'installation de la version 5 implique 15 dépendances d'exécution directes : avvio, find-my-way, fast-json-stringify, light-my-request, pino, secure-json-parse, semver, rfdc, toad-cache, process-warning, abstract-logging, ainsi que quatre @fastify/* . Pour un framework web, il s'agit là d'un ensemble de dépendances directes véritablement restreint.

Le fait d’atteindre la fin de vie (EOL) ne fige pas l’arborescence en soi, et il convient d’être précis sur ce qui se passe réellement. Fastify définit des plages de versions selon la norme Semver, et npm met à jour les dépendances vers des versions plus récentes qui restent conformes à ces plages ; ainsi, de nombreux correctifs de sécurité en amont sont intégrés sans que personne n'ait à intervenir sur Fastify. Le problème est plus spécifique et plus gênant qu'un simple arbre figé. Lorsque la seule version corrigée se situe en dehors de la plage acceptée par votre version de Fastify, son adoption implique une dérogation, une modification directe des dépendances ou une mise à niveau du framework pour laquelle votre version n'a jamais été testée.

Votre scanner signale donc un avis transitif, et la solution de correction « propre » s’avère être « la mise à niveau de Fastify », ce que vous cherchiez justement à éviter. Pour une application v3, cela implique généralement une mise à niveau de Node.js ainsi que des modifications du schéma et de l’API, et non pas la publication d’un correctif. C’est à cause de cet écart qu’un audit initialement « propre » se transforme en un trimestre de discussions avec votre équipe de sécurité sur la distinction entre les risques acceptables et les faux positifs.

Vos options après la fin de vie de Fastify

Il existe trois options, et le choix de la bonne dépend moins des préférences techniques que de la version que vous utilisez réellement et du temps dont dispose votre équipe ce trimestre.

Si cela vous correspond	Faites ceci
Utilisation de la version 3 ou 4 dans un environnement réglementé, sans marge de manœuvre pour une migration du moteur d'exécution et du framework ce trimestre	Bénéficiez d'un support prolongé pour votre version actuelle, puis effectuez la migration au moment qui vous convient
Fonctionne déjà sur une version prise en charge de Node.js, peu d'API obsolètes, plugins maintenus	Passez dès maintenant à la version 5
Ce framework n'est pas adapté au-delà du problème de fin de vie	Remplacez-le et prévoyez un budget adéquat

 Assistance tout au long du cycle de vie proposée par TuxCare

Le service « Endless Lifecycle Support » (ELS) de TuxCare couvre les environnements d’exécution, bibliothèques et frameworks open source en fin de vie (EOL). Il fournit des correctifs de sécurité rétroportés pour les versions que le projet en amont ne maintient plus, via la gestion standard des paquets, ce qui réduit au minimum les modifications à apporter à votre pipeline de déploiement. Pour Fastify en particulier, les versions couvertes sont les 3.29.5 et 4.29.1, les dernières versions des séries v3 et v4. Les correctifs sont diffusés via npm et font l’objet d’un suivi public dans CVE Tracker de TuxCare, ce qui permet à votre équipe de sécurité de voir exactement ce qui est couvert avant de donner son accord.

Pour une équipe bloquée sur une version Fastify en fin de vie (EOL), qu’il s’agisse d’un parc de version 4 dont la période de support à long terme (LTS) est dépassée depuis un an ou d’un parc de version 3 dont cette période est dépassée depuis trois ans, cela permet de continuer à bénéficier des correctifs de sécurité pour la version déjà en production, plutôt que de devoir passer de force à la version 5, ce qui entraînerait une mise à niveau vers plusieurs versions de Node.js. Cela permet également de disposer d’une documentation sur les correctifs que vous pouvez présenter lors d’un audit SOC 2 ou PCI DSS, ainsi que d’un calendrier de migration que vous définissez vous-même, plutôt que celui dicté par un calendrier de publication ou les conclusions d’un auditeur.

Les équipes qui se retrouvent dans cette situation ne sont pas paresseuses. Elles sont confrontées à de réelles contraintes : les limites de compatibilité des plateformes, des ressources d’ingénierie déjà mobilisées, la complexité des tests sur des dizaines de services, ou encore des règles réglementaires qui transforment une mise à niveau imprévue du framework en un problème de contrôle des changements plutôt qu’en un simple problème technique. Pour un service de la génération v3, cela s’apparente souvent davantage à une refonte complète de la plateforme qu’à une simple mise à jour de version.

Le rôle de TuxCare dans ce contexte est de servir de passerelle, en veillant à ce que la version de Fastify prise en charge reste à jour, tandis que la migration s'effectue selon votre propre calendrier, et non selon celui de l'amont.

Passer à Fastify v5

C'est la bonne décision à prendre lorsque vous en avez les moyens, et pour un parc de version 4, le changement est moins important que ce qui est généralement le cas lors des mises à niveau vers une nouvelle version majeure. Le guide de migration de Fastify est vraiment succinct. Pour un parc de serveurs en version 3, prévoyez un budget plus proche de celui d’une refonte de la plateforme, avec deux versions majeures d’API obsolètes à traiter, ainsi qu’un changement de runtime, passant de la version de Node en fin de vie (EOL) sur laquelle le service repose actuellement à une version actuellement prise en charge.

Quatre éléments déterminent cette estimation. Le premier est l'environnement d'exécution, car la version 5 nécessite Node.js 20 ou une version plus récente, et ce point est incontournable. Étant donné que Node 20 arrivera lui-même en fin de vie en avril 2026, une nouvelle migration devrait s'effectuer vers une version LTS actuellement prise en charge, ce qui, fin 2026, signifie Node 24 plutôt que de s'arrêter à la version 20.

Le second est un schéma JSON complet. Le option jsonShorthand a disparu, et lorsque vous utilisez le validateur par défaut, « querystring », params, bodyet « response » doivent tous comporter des objets de schéma complets, y compris le propriété « type » .

Le troisième point concerne les API supprimées. Fastify v5 a supprimé les API qui avaient été dépréciées au cours du cycle de vie de la v4 ; les avertissements de dépréciation que vous avez jusqu'à présent ignorés dans vos journaux constituent donc un bon point de départ pour établir votre liste de tâches. Si vous venez de la v3, cela représente deux cycles de dépréciation à traiter au lieu d'un seul.

Le quatrième point concerne la compatibilité avec les plugins. Chaque plugin @fastify/* et les plugins communautaires doivent disposer d'une version compatible avec la v5, et c'est généralement là que le calendrier prend du retard. C'est particulièrement le cas pour les anciens ensembles de plugins que personne n'a mis à jour depuis 2022.

Si votre ensemble de plugins est entièrement développé en interne et activement maintenu, et que vous passez de la version 4, le travail à effectuer reste généralement limité. Si vous passez de la version 3, ou si vous utilisez des plugins communautaires qui ne sont plus mis à jour depuis des années, évaluez d’abord l’ampleur du travail de remplacement. C’est cette partie qui peut transformer une mise à jour simple en un projet de migration nettement plus important.

Remplacer Fastify

Changer de framework pour résoudre un problème de fin de vie (EOL) revient presque toujours plus cher qu’une mise à niveau, et cela vaut doublement à partir de la v3, où, de toute façon, vous devrez déjà procéder à une refonte importante. Express 5, Hapi et Hono sont tous des frameworks valables, mais passer à l’un d’entre eux peut impliquer un travail considérable au niveau de l’enregistrement des routes, des hooks et des middlewares, de la validation, des plugins et du code applicatif spécifique au framework. Il s’agit là d’une refonte déguisée en mise à niveau. Optez pour cette solution si Fastify ne vous convient vraiment pas, et non pas simplement parce que la version est arrivée en fin de vie.

Assurez la sécurité de Fastify au-delà de la fin de vie avec TuxCare

La version 3 de Fastify a atteint la fin de son cycle de support à long terme (LTS) en juin 2023, suivie par la version 4 en juin 2025. Aucune de ces deux dates ne constituait en soi un événement à risque. Le risque réside dans le délai qui s'écoule entre la date applicable à votre parc et le jour où votre dernier service en fin de vie (EOL) sera déployé sur une plateforme prise en charge ; pour de nombreuses équipes, ce délai se mesure au mieux en trimestres et, au pire, en années.

Vous avez le choix entre deux solutions. Passez dès maintenant à la version 5 et acceptez la mise à niveau du runtime qui l’accompagne, ou continuez à appliquer des correctifs à la version que vous utilisez actuellement, y compris les versions 3.29.5 et 4.29.1, tout en effectuant la migration selon un calendrier que vous contrôlez réellement. Ces deux positions sont défendables. Continuer à utiliser une version en fin de vie (EOL) en espérant que tout ira bien ne l’est pas.

Si vous faites partie de ce deuxième groupe, le service « Endless Lifecycle Support » de TuxCare prend en charge les frameworks et les environnements d'exécution en fin de vie, notamment Fastify 3.29.5 et 4.29.1, en les mettant à jour et en les préparant pour les audits aussi longtemps que votre entreprise en a besoin.

FAQ