Fin de vie de Flask : risques et options pour les versions non prises en charge

Accédez directement au résumé généré par l'IA de cet article de blog

Principaux enseignements

Votre exposition va au-delà de Flask lui-même : Flask utilise six dépendances directes, chacune ayant son propre historique de vulnérabilités CVE.
Les migrations précipitées ont un coût réel : les mises à niveau précipitées endommagent les extensions, obligent à passer à une version supérieure de Python et dépassent les estimations initiales.
La fin de vie ne signifie pas nécessairement l'absence de correctifs : Grâce au support étendu, les versions de Flask en fin de vie continuent de bénéficier de correctifs de sécurité pendant que vous planifiez la mise à niveau.

Si vous utilisez Flask en production, vous avez sans doute déjà vécu ce genre de situation. Peut-être s’agissait-il d’un avertissement de pip-audit signalant une ancienne version dans votre fichier requirements.txt. Peut-être s’agissait-il d’un e-mail de l’équipe de sécurité vous demandant quelles étaient les versions de vos frameworks. Peut-être s’agissait-il d’un collègue vous transférant un avis CVE avec pour objet « Est-ce que cela nous concerne ? ».

Et puis vient la question que personne ne veut aborder : « Quelle est la version de Flask que nous utilisons, et que faudrait-il faire pour la mettre à jour ? »

Pallets, l’organisation à l’origine de Flask, ne prend en charge que la dernière version en date. Si vous n’utilisez pas cette version, vous vous trouvez en territoire non pris en charge, et les risques sont plus importants que ne le pensent de nombreuses équipes. Mais la fin de vie de Flask ne doit pas nécessairement être synonyme de panique. Vous disposez de plus d’options que vous ne le pensez. Voyons ensemble ce qu’implique l’utilisation d’une version non prise en charge de Flask pour votre environnement de production et, surtout, ce que vous pouvez réellement faire pour y remédier sans bouleverser votre feuille de route technique.

Comment fonctionnent réellement les versions de Flask ?

Avant d'aborder la question de savoir « comment y remédier », il est utile de comprendre comment Flask gère le cycle de vie de ses versions, car son approche diffère de celle de la plupart des frameworks, ce qui a des implications directes sur votre niveau de sécurité.

Flask ne suit pas un modèle de support à long terme avec des dates de fin de vie (EOL) définies, comme c'est le cas pour Angular ou Node.js. À la place, Pallets (l'organisation qui assure la maintenance de Flask) publie une politique de prise en charge des versions qui est concise et explicite : la dernière version fonctionnelle bénéficie de corrections de bogues et de failles de sécurité, contrairement aux versions antérieures. En fonction de la gravité du problème et de l’effort requis, une correction de sécurité peut, sur demande, être rétroportée sur la version précédente, mais cela n’est pas garanti. En pratique, lorsqu’une nouvelle version fonctionnelle est publiée, la version précédente cesse de recevoir des mises à jour, y compris les correctifs de sécurité.

L'historique des versions se présente comme suit : la version 1.0 est sortie en avril 2018, suivie de la version 1.1 en juillet 2019. Flask 2.0 a été lancé en mai 2021, ajoutant la prise en charge des fonctions de vue asynchrones et rehaussant les versions minimales requises dans l'ensemble de l'écosystème Pallets. Les versions 2.1, 2.2 et 2.3 ont suivi entre 2022 et 2023. Flask 3.0 a été lancé en septembre 2023 ; il nécessite Werkzeug 3.0 et s'appuie sur le nettoyage de l'API entamé avec Flask 2.3. Flask 3.1.0 a été publié en novembre 2024, et la dernière version en date d'août 2026 est Flask 3.1.3, publiée en février 2026 – il s'agit d'une version de correction de sécurité.

Cette politique a une conséquence précise. La branche de développement actuelle est la 3.1.x ; vous devez donc utiliser sa dernière version corrective pour bénéficier d'une prise en charge complète. Toute version 3.0.x ou antérieure se trouve hors de la période de prise en charge, et il ne faut pas s'attendre à ce que les vulnérabilités récemment découvertes affectant ces branches fassent l'objet d'un correctif en amont.

Ce que signifie réellement la fin de vie de Flask pour votre API de production

Bon, d'accord, votre version n'est pas la plus récente. Votre application fonctionne correctement, vos points de terminaison répondent et votre pipeline d'intégration continue affiche le statut « vert ». Alors, quel est le problème ?

La découverte de vulnérabilités ne s'arrête pas pour autant qu'une branche de version cesse de recevoir des correctifs. Et chaque avis de sécurité publié précise exactement quelles versions sont concernées, ce qui signifie qu'un déploiement qui n'est plus pris en charge accumule des failles documentées et définitivement non corrigées, que n'importe qui peut consulter.

L'historique des vulnérabilités CVE de Flask en est la preuve concrète. L'exemple le plus connu est CVE-2023-30861 (CVSS 7,5, risque élevé), un problème de divulgation de cookies de session qui a donné lieu à la publication de bulletins de sécurité par les éditeurs intégrant Flask dans leurs produits d’entreprise, notamment IBM Maximo Application Suite.

La faille sous-jacente était mineure. Flask définit un en-tête de réponse « Vary: Cookie » lorsque la session est utilisée, ce qui indique aux caches de ne pas servir cette réponse à un autre utilisateur. Dans un scénario de session permanente, Flask actualisait le cookie de session sans considérer que la session avait été consultée ; par conséquent, l’en-tête était absent alors qu’un en-tête « Set-Cookie » était présent. Dans le cas d’un proxy de mise en cache qui ne supprime pas les cookies, d’une session permanente, du paramètre `SESSION_REFRESH_EACH_REQUEST` laissé à sa valeur par défaut et de l’absence d’en-tête `Cache-Control` explicite, une réponse contenant le cookie de session d’un utilisateur pouvait être mise en cache et servie à un autre utilisateur. Lorsque le cookie de session contrôle l’accès à un compte authentifié, il ne s’agit pas d’un cas limite théorique.

Pallets a corrigé ce problème dans les versions 2.3.2 et 2.2.5 de Flask – respectivement la branche de fonctionnalités alors en vigueur et celle qui la précédait –, conformément à la politique de support. Aucun correctif n'a été publié pour les versions 2.1.x ou antérieures ; les équipes utilisant ces versions ne disposaient donc d'aucun correctif en amont à installer.

Si cela ressemble à de l'histoire ancienne, ce n'est pas le cas. En février 2026, Pallets a révélé CVE-2026-27205, un problème de même nature : la session n’était pas marquée comme ayant été consultée lorsque le code ne vérifiait que ses clés, à l’aide d’opérateurs tels que `in` et `len`, de sorte que le `Vary: Cookie` était à nouveau omis dans des conditions de mise en cache comparables. Cela affecte toutes les versions de Flask antérieures à la 3.1.3 – c’est-à-dire toutes les versions en fin de vie encore utilisées aujourd’hui. Flask 3.1.1 avait déjà intégré un correctif distinct concernant la signature de session (CVE-2025-47278) en mai 2025. Trois versions de sécurité en trois ans, et seule la branche actuelle en a bénéficié.

Les cadres de conformité ajoutent une deuxième dimension. L’exigence 6.3.3 de la norme PCI DSS v4.0.1 impose l’installation des correctifs pour les vulnérabilités critiques dans un délai d’un mois à compter de leur publication. Lorsqu’aucune version corrigée n’existe pour votre version, ce délai ne commence jamais à courir et la non-conformité reste ouverte. Les évaluations SOC 2 et autres évaluations similaires basées sur les contrôles n’interdisent pas purement et simplement les composants non pris en charge, mais elles exigent une évaluation des risques documentée, des contrôles compensatoires ou une stratégie crédible pour obtenir des correctifs. L’utilisation d’une version non prise en charge de Flask sans qu’aucun de ces éléments ne soit en place constitue une lacune sur laquelle un évaluateur vous interrogera.

Le risque caché : l'arborescence des dépendances de Flask

Lorsque les équipes réfléchissent à la sécurité de Flask, elles pensent au framework lui-même : le routage, le contexte de requête, la gestion des sessions. C'est la couche la plus évidente.

Mais ce framework ne fonctionne pas de manière isolée. L’installation de la version actuelle de Flask entraîne également l’installation de six dépendances directes d’exécution : Werkzeug (couche WSGI et analyse des requêtes), Jinja2 (génération de modèles), MarkupSafe (échappement des chaînes de caractères pour une intégration sécurisée dans le balisage), ItsDangerous (signature des cookies de session), Click (outils en ligne de commande) et Blinker (signaux). Sous Python 3.9, il en existe une septième : importlib-metadata. Chacune possède son propre historique de vulnérabilités CVE et son propre rythme de publication, et l'ensemble exact varie selon la version de Flask – Blinker, par exemple, n'est devenu obligatoire qu'à partir de Flask 2.3.

Ce qui rend la situation délicate, c’est le lien très étroit entre les versions. Flask 3.1.0 nécessite Werkzeug 3.1 ou une version plus récente, ItsDangerous 2.2 ou une version plus récente, et Blinker 1.9 ou une version plus récente. Flask spécifie des versions minimales plutôt que des numéros de version exacts ; ainsi, une ancienne version de Flask ne bloque pas à elle seule l’ensemble de votre arborescence. La contrainte pratique vient de l’autre sens : une vulnérabilité dans l’analyse des requêtes de Werkzeug ou dans la logique de signature d’ItsDangerous affecte votre application aussi directement qu’une faille dans Flask, et la mise à jour de ce seul paquet peut rompre la compatibilité avec votre version de Flask, vos extensions ou votre propre code.

Vous pouvez également en savoir plus sur les problèmes de sécurité liés à Python et sur les risques susceptibles d'affecter les applications au sein de l'écosystème Python au sens large.

Vos options à l'approche de la fin de vie de Flask

Bon, vous utilisez donc une version de Flask qui n'est plus prise en charge. Quelles sont les solutions réalistes qui s'offrent à vous ?

Il en existe trois, et chacun présente des avantages et des inconvénients différents. La mise à niveau ou la migration réduit le risque lié aux systèmes hérités à long terme, mais peut nécessiter un travail d'ingénierie considérable. La prolongation de la prise en charge comble la faille de sécurité immédiate et permet de gagner du temps pour mener à bien ce travail dans les règles de l'art.

Option 1 : Passer à la dernière version prise en charge de Flask

Voici la réponse officielle : passez à la branche de version actuelle (Flask 3.1.x à la date de rédaction de cet article), installez les derniers correctifs de sécurité et restez à jour. Pour les équipes disposant de bases de code bien entretenues, c'est la bonne stratégie à long terme.

Flask 3.x apporte de réelles améliorations. La prise en charge des fonctions de vue asynchrones, introduite dans la version 2.0, a continué à évoluer, même si Flask reste un framework WSGI plutôt qu’un framework axé en priorité sur l’asynchronisme. La refonte « Sans-IO » de la version 3.0 a séparé la logique centrale de Flask de son infrastructure WSGI, ce qui permet à des projets tels que Quart de le réutiliser. Les versions des dépendances sont à jour et maintenues. Si vous pouvez effectuer une mise à jour sans problème, n’hésitez pas à le faire.

Mais voici ce qu'implique la « mise à jour vers la dernière version » lorsque vous venez de Flask 1.x ou des premières versions de la 2.x :

Configuration requise pour Python : Flask 3.0 nécessite au minimum Python 3.8, et Flask 3.1 a relevé ce seuil à Python 3.9, abandonnant complètement la version 3.8. Si votre environnement de production utilise une version plus ancienne de Python – ce qui est courant dans les applications héritées et dans les conteneurs construits à partir d’images de base fixes –, une mise à niveau de Python devient une condition préalable avant de pouvoir utiliser Flask.

Extensions non compatibles : C’est le point le plus important. L’écosystème de Flask comprend Flask-Login, Flask-SQLAlchemy, Flask-Migrate, Flask-Admin et des dizaines d’autres extensions, chacune ayant ses propres exigences de compatibilité. Lorsque Flask 3.0 a été lancé aux côtés de Werkzeug 3.0 le 30 septembre 2023, Werkzeug a supprimé les fonctions d’aide url_decode et url_encode, obsolètes depuis longtemps, que Flask-Login 0.6.2 importait lors du chargement du module. Les applications qui avaient adopté la nouvelle version de Werkzeug ne parvenaient pas à démarrer et généraient une erreur `ImportError` ; le correctif n’a été intégré qu’à partir de la version 0.6.3 de Flask-Login, le 30 octobre – soit un mois de dysfonctionnement pour l’une des extensions les plus utilisées de Flask. Toute application s’appuyant sur plus d’une poignée d’extensions est exposée à ce même risque de coordination à chaque mise à jour majeure.

Suppression des API obsolètes : Flask 2.3.0 a supprimé un ensemble d'API qui avaient été dépréciées dans la version 2.2, notamment app.before_first_request, bp.before_app_first_request, le json_encoder et json_decoder , ainsi que l’attribut variable d’environnement FLASK_ENV et la valeur de la variable send_file_max_age_default, use_x_sendfileet propagate_exceptions de l’application. Flask 3.0 n’a réintroduit aucune d’entre elles. Le code d’application ou les extensions utilisant encore ces API cesseront de fonctionner dès que votre parcours de mise à niveau atteindra la version 2.3. Cela est particulièrement important lorsque vous passez directement de la version 1.x ou des premières versions 2.x à la version 3.x : vous héritez à la fois des suppressions de la version 2.3 et des modifications de la version 3.0 au cours de la même migration.

Cascade de compatibilité de Werkzeug : Werkzeug étant étroitement lié à Flask, la mise à jour de Flask implique généralement celle de Werkzeug, ce qui peut avoir des répercussions sur les extensions, les middlewares personnalisés et tout code intervenant directement sur le fonctionnement interne de Werkzeug.

Pour une petite application Flask activement maintenue, cela pourrait se traduire par un sprint ciblé. En revanche, pour une API de grande envergure, avec des années de pratiques accumulées, des extensions personnalisées et une exigence de disponibilité pendant la migration, cela implique une planification minutieuse, des tests exhaustifs et un risque réel de régressions en production.

Comprendre Werkzeug Security avant de mettre à jour Flask.

Option 2 : Migrer vers un autre cadre

Certaines équipes, face à une mise à jour de Flask, se disent : « C'est peut-être le moment de tout repenser. »

FastAPI se distingue par sa documentation automatique des API, sa prise en charge native de l'asynchronisme et sa validation basée sur Pydantic. Django REST Framework propose une approche « tout compris » aux équipes qui privilégient les conventions à la configuration. Starlette offre une base ASGI légère pour les piles d'API personnalisées.

Il existe de véritables arguments techniques en faveur de chacune de ces options, en fonction de vos besoins et de l'orientation choisie par votre équipe.

Mais soyez clair sur l’étendue de la tâche. Vous ne vous contentez pas de remplacer une dépendance. Vous réécrivez les gestionnaires de routes pour les adapter à une interface API différente, vous remplacez le modèle de contexte de requête de Flask, vous remaniez l’authentification et la gestion des sessions, et vous devez trouver des équivalents pour les extensions Flask dont vous dépendez – Flask-Login, Flask-SQLAlchemy, Flask-Migrate – ou reconstruire cette logique vous-même.

Les avantages à long terme peuvent justifier cet effort dans un contexte approprié. Le calendrier et les coûts ont tendance à dépasser les estimations initiales une fois que l'étendue totale du projet est définie, et la maintenance de l'application Flask existante parallèlement au développement de son remplaçant entraîne des coûts supplémentaires.

Option 3 : Assistance étendue par un tiers

L'option que les équipes négligent le plus souvent est le support de sécurité étendu proposé par un fournisseur spécialisé.

TuxCare propose un support à durée de vie illimitée (ELS) pour les versions de Flask en fin de vie. Ainsi, vous n’êtes pas obligé de migrer avant d’être prêt, ni de laisser vos API exposées pendant que vous planifiez cette migration : vous pouvez continuer à utiliser une version de Flask prise en charge, tout en bénéficiant de correctifs de sécurité.

Le principe est simple : vous gagnez du temps et du contrôle. Du temps pour planifier une mise à niveau adaptée, au moment qui convient le mieux à votre équipe et à votre application. Et le contrôle sur le calendrier de votre migration, plutôt que de laisser une divulgation de vulnérabilité le déterminer à votre place au pire moment possible.

Le coût réel d'une mise à niveau précipitée de la fin de vie d'un flacon

Imaginez ce qui se passe lorsqu'une équipe est contrainte de condenser une migration Flask dans un délai irréaliste parce qu'un audit de sécurité a mis en évidence des dépendances non prises en charge.

Augmentation de la charge de support : Des problèmes de compatibilité qui n’étaient pas apparus lors des tests intensifs commencent à se manifester en production. Une extension qui fonctionnait dans l’environnement de test se comporte différemment sous la charge. Votre file d’attente d’assistance se remplit de problèmes liés à la migration, et leur diagnostic nécessite une connaissance approfondie des changements intervenus au niveau des différentes dépendances.

Instabilité du système : Une mise à jour de la version de Werkzeug modifie la manière dont les données des formulaires à plusieurs parties sont analysées, et un point de terminaison de téléchargement commence à rejeter des fichiers qu’il acceptait auparavant. Une modification de la gestion des sessions provoque des échecs d’authentification intermittents qui n’apparaissent que sous des profils de charge spécifiques. Ce sont ces problèmes qui génèrent des alertes à 3 heures du matin et entraînent le non-respect des SLA.

Accumulation de dette technique : Dans leur empressement à se mettre en conformité, les équipes prennent des raccourcis. L’utilisation d’API obsolètes est masquée par des couches de compatibilité au lieu d’être correctement refactorisée. « Nous nettoierons tout cela après la migration » devient une habitude, et six mois plus tard, vous vous retrouvez avec une base de code techniquement à jour, mais truffée de solutions de contournement et de nettoyages reportés.

Dépassements budgétaires : L’estimation initiale était de deux semaines. Cinq semaines plus tard, vous êtes toujours en train de traquer des problèmes de compatibilité avec les extensions, le prestataire continue de facturer, les fonctionnalités ont été reportées et les ingénieurs, qui devraient développer de nouvelles fonctionnalités, sont en train de déboguer des conflits de versions.

La différence entre une mise à niveau de Flask bien planifiée et une mise à niveau effectuée dans la précipitation n’est pas négligeable. C’est la différence entre un projet maîtrisé, dont le périmètre est clairement défini, et une succession d’urgences qui mobilise les ressources de votre équipe pendant des mois.

Assurer la sécurité des flasks en fin de vie grâce à TuxCare

C'est là que le « soutien tout au long du cycle de vie » proposé par TuxCare change la donne.

Depuis 15 ans, TuxCare fournit des correctifs de sécurité pour les systèmes d'exploitation, les environnements d'exécution, les bibliothèques et les frameworks d'applications en fin de vie. L'entreprise fait état de plus de 220 000 correctifs fournis et de plus de 5 000 vulnérabilités CVE corrigées sur quelque 10 000 paquets pour plus de 2 300 entreprises clientes – un bilan établi dans des environnements de production, et non pas une simple série de promesses à ce sujet.

En quoi l'approche de TuxCare est-elle différente ?

Couverture de l’ensemble de la chaîne de dépendances : Le risque lié à la fin de vie d’un produit se limite rarement au paquet de niveau supérieur. Pour une application Flask, il s’étend à Werkzeug, Jinja2, MarkupSafe, ItsDangerous et à tout ce qui se trouve en aval. Lorsqu’une dépendance couverte nécessite un correctif de sécurité, TuxCare applique les correctifs, recompile et valide l’ensemble des paquets concernés, plutôt que de vous laisser mettre à jour un composant seul et découvrir par vous-même ce qu’il perturbe. La couverture des dépendances directes et transitives est incluse sans frais supplémentaires.

Backport automatisé avec validation par des experts : TuxCare suit de près le NVD, les avis des éditeurs et les flux de sécurité GitHub, puis effectue le backport des correctifs à l’aide d’une automatisation algorithmique et assistée par l’IA, le résultat étant validé par des ingénieurs en sécurité. Les paquets sont soumis à des tests d’intégrité, de fonctionnalité et de régression, puis signés avant d’être intégrés aux dépôts des clients. Pour découvrir le fonctionnement de ce processus de bout en bout, consultez le livre blanc technique de TuxCare consacré à son processus de correction des logiciels open source.

Distribution via votre workflow pip existant : Les paquets corrigés sont distribués à partir d'un dépôt hébergé par TuxCare que vous configurez en tant qu'index pip ou index supplémentaire. Vous n'avez pas besoin de remanier votre pipeline de compilation, de former à nouveau votre équipe ni de modifier votre processus de déploiement : il vous suffit de pointer vers une source qui continue de produire des correctifs même après que Pallets a cessé ses activités.

Délais de réponse garantis par le SLA : Les objectifs publiés par TuxCare pour son service « Endless Lifecycle Support for Libraries » prévoient la mise à disposition de correctifs dans les 14 jours suivant la divulgation publique pour les vulnérabilités à risque élevé et critique (CVSS 7.0 et plus), dans les 60 jours pour celles à risque moyen, et dans les 90 jours pour celles à faible risque. Vous disposez ainsi de délais clairement définis, autour desquels vous pouvez planifier une fenêtre de correction, avec une assistance disponible 24 h/24 et 7 j/7.

Coût prévisible : Le support étendu est facturé à un tarif fixe pendant toute la durée du contrat, ce qui facilite la comparaison avec une migration. Comparez ce chiffre aux heures d’ingénierie, aux cycles de test, aux honoraires des prestataires, aux temps d’arrêt potentiels et aux fonctionnalités retardées qu’impliquerait une mise à niveau accélérée, et vous comparerez deux chiffres concrets au lieu d’un chiffre et d’un espoir.

Documentation prête pour les audits : Chaque version est accompagnée d’informations indiquant les CVE qui ont été corrigées et les versions des paquets qui ont été modifiées, ainsi que des SBOM lisibles par machine (SPDX et CycloneDX) et des documents VEX. Ce sont là les preuves requises dans le cadre des audits de gestion des vulnérabilités et de contrôle des changements, bien que les exigences spécifiques dépendent toujours du cadre de référence, des limites de votre système et de votre auditeur.

Comment démarrer

Si vous utilisez une version de Flask en fin de vie et que vous souhaitez évaluer votre niveau d'exposition, TuxCare met à jour un outil de suivi des CVE qui répertorie les vulnérabilités associées aux versions de Flask prises en charge, ainsi que les correctifs publiés pour celles-ci. La couverture actuellement publiée inclut les versions Flask 0.12.5, 1.1.2, 1.1.4 et 2.2.1 ; d'autres versions sont disponibles sur demande.

Vérifier les vulnérabilités et les correctifs ELS disponibles pour Flask.

Ne laissez pas la fin de vie de Flask mettre vos API en danger

Se limiter à la prise en charge de la dernière version en date constitue une approche pragmatique pour une petite équipe open source. Cette solution s'avère toutefois moins pratique pour les organisations exploitant des applications en production qui ne peuvent pas effectuer de mise à jour à chaque nouvelle version.

Ce qu’il faut retenir, c’est que la fin de vie de Flask ne doit pas nécessairement être synonyme de précipitation. Plusieurs options s’offrent à vous. Vous pouvez planifier une mise à niveau mûrement réfléchie au moment qui convient le mieux à votre équipe, évaluer un autre framework s’il existe une véritable raison architecturale de changer, ou recourir au support étendu pour continuer à bénéficier des correctifs de sécurité et respecter vos obligations de conformité, tout en prenant ces décisions selon votre propre calendrier plutôt que selon celui d’un auditeur.

Les équipes qui gèrent au mieux la fin de vie de Flask sont celles qui identifient le risque dès le début, comprennent les options qui s'offrent à elles et font des choix mûrement réfléchis plutôt que des choix dictés par la situation.

Si la fin de vie de Flask vous préoccupe, cela vaut la peine de découvrir ce qu’est le service « Endless Lifecycle Support » de TuxCare de TuxCare. La meilleure chose à faire pourrait être de sécuriser la version que vous utilisez déjà, tout en planifiant la mise à niveau que vous souhaitez réellement effectuer.

Résumé