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
- Un outil non pris en charge signifie que les correctifs en amont s'arrêtent, laissant les applications concernées sans correctif en amont lorsque de nouvelles vulnérabilités apparaissent.
- Les mises à niveau précipitées peuvent introduire des bogues en production, des problèmes de dépendances, une dette technique et des coûts imprévus.
- TuxCare ELS maintient les anciennes versions de Werkzeug à jour pendant que vous planifiez le moment opportun pour la mise à niveau.
Vous avez construit une application robuste sur Werkzeug. Le routage fonctionne. La gestion des requêtes est propre. La couche WSGI remplit parfaitement son rôle. Soudain, votre outil d'analyse des dépendances se déclenche, ou un membre de l'équipe de sécurité demande quelle version de Werkzeug est exécutée dans le conteneur, et la réponse s'avère être la version 2.2.3, une version datant de 2023.
Et maintenant ?
Ce problème est plus fréquent qu'il n'y paraît, principalement parce que presque personne ne choisit sa version de Werkzeug intentionnellement. Flask l'installe, pip la résout, et elle reste en suspens jusqu'à ce qu'un événement vienne perturber le processus. Voyons donc ce qui se passe concrètement lorsqu'une branche Werkzeug cesse d'être mise à jour, et ce que vous pouvez faire pour y remédier.
Comment fonctionnent réellement les sorties Werkzeug
Werkzeug est maintenu par le projet Pallets, au même titre que Flask, Jinja et Click. Contrairement à Python ou Node.js, Pallets ne publie pas de calendrier de support à long terme avec des fenêtres de maintenance fixes pour chaque branche. Aucune date de fin de vie n'est annoncée pour Werkzeug 2.2. Le support assuré doit donc être déduit des versions effectivement distribuées par les mainteneurs.
La structure générale est assez facile à appréhender. Werkzeug 2.x a abandonné Python 2 et 3.5 et a orienté le code vers les annotations de type. Werkzeug 3.x a poursuivi cette évolution, en supprimant les API obsolètes et en relevant la version minimale requise de Python ; elle exige désormais Python 3.9 ou une version ultérieure. La branche active actuelle est la 3.1.x, la version 3.1.8, sortie le 2 avril 2026, étant la dernière version stable en date d'août 2026.
Voici le point qui prête à confusion. Le modèle intuitif selon lequel une nouvelle version majeure remplace immédiatement la version précédente n'est pas fiable. Werkzeug 3.0.0 a été publié fin septembre 2023, et la version 2.3.8 est arrivée le 8 novembre 2023, intégrant un correctif de sécurité. Les rétroportages existent bel et bien. Ils sont simplement imprévisibles et non garantis.
L'historique des versions révèle surtout où se porte l'attention. La branche 3.0 a reçu sa dernière version, la 3.0.6, fin octobre 2024, quelques jours avant la sortie de la 3.1.0, et aucune nouvelle version n'a été publiée depuis. La branche 2.x s'est arrêtée à la version 2.3.8. En pratique, seule la branche 3.1.x reçoit encore des mises à jour, tandis que les branches précédentes semblent inactives sans avoir jamais été officiellement déclarées abandonnées. C'est sans doute pire qu'une date de fin de vie publiée, car il est impossible de se référer à un calendrier pour un auditeur et de planifier une maintenance qui n'a jamais été annoncée.
Si vous n'êtes pas sûr de votre position, pip show werkzeug La réponse est donnée en deux secondes environ. Si la version ne commence pas par 3.1, ne comptez pas sur la publication d'un correctif par les développeurs de la version précédente pour la prochaine version divulguée.
Que signifie réellement un Werkzeug non supporté en production ?
L'assistance technique prend fin. L'application continue de fonctionner. Rien ne semble dysfonctionner. Alors, pourquoi est-ce important ?
L'arrêt des correctifs ne fait pas disparaître les vulnérabilités. Le risque ne réside pas dans le fait que les attaquants tiennent une liste des applications Werkzeug en retard. C'est plus simple et moins problématique. Une faille est découverte, elle affecte votre branche et il n'existe aucune solution de correction en amont. Werkzeug étant basé sur Flask, cette faille est héritée par tout ce que vous avez construit par-dessus.
Deux révélations illustrent bien le problème.
La vulnérabilité CVE-2024-34069 affecte le débogueur interactif de Werkzeug et est classée comme critique (7,5/10) par NVD et Pallets Advisory. Son exploitation est limitée : un attaquant doit inciter un développeur à interagir avec un domaine et un sous-domaine qu'il contrôle, lui faire saisir le code PIN du débogueur et deviner l'URL de l'application qui déclenche le débogueur. Si ces trois conditions sont réunies, du code peut être exécuté sur la machine du développeur, même si le débogueur est configuré pour utiliser localhost. Cette vulnérabilité a été corrigée dans la version 3.0.3.
C'est précisément le but de cette correction. Werkzeug 3.0.3 est la première version à l'intégrer, et toutes les versions 3.x ultérieures l'incluent. Il n'existe aucune version 2.x avec ce correctif, y compris la version 2.3.8, la dernière version 2.x. Si votre environnement est basé sur la branche 2.x, aucune version de cette branche ne vous permettra de résoudre ce problème.
En savoir plus sur Werkzeug Security et les vulnérabilités actuelles.
La vulnérabilité CVE-2023-46136 est une attaque par déni de service (DoS) dans l'analyseur de formulaires multipart. Si un chargement commence par un retour chariot (CR) ou un saut de ligne (LF) suivi de plusieurs mégaoctets sans ces caractères, l'analyseur ajoute les octets par blocs dans un tableau d'octets interne et analyse à nouveau le tampon en expansion pour détecter la limite, ce qui sature le processeur et empêche le processus de traiter d'autres données. Cette vulnérabilité affecte les versions 2.3.7 et antérieures, ainsi que la version 3.0.0, et a été corrigée dans les versions 2.3.8 et 3.0.1. À noter avant de soulever ce problème dans un ticket : NVD lui attribue une note de 7,5 (Élevée), tandis que l'avis de sécurité de Pallets lui attribue une note de 5,7 (Modérée), car les deux divergent quant au vecteur d'attaque et aux privilèges requis. Différents scanners peuvent attribuer des notes de gravité différentes selon le flux de données utilisé. Cette vulnérabilité concerne les applications dont un point de terminaison analyse des données multipart fournies par un attaquant.
Sur une branche maintenue, ces deux actions entraînent une mise à jour de version. Sur une branche non maintenue, une vulnérabilité nouvellement découverte reste non corrigée en amont jusqu'à ce que vous mettiez à jour le code ou que vous installiez un correctif ailleurs.
Risques liés à la sécurité et à la conformité après la fin du support
La norme PCI DSS v4.0.1, actuellement en vigueur, exige, conformément à l'exigence 6.3.3, que les correctifs pour les vulnérabilités critiques soient installés dans le mois suivant leur publication. Les autres correctifs applicables sont traités selon le calendrier d'évaluation des risques documenté de l'organisation. La version 4.0 avait étendu ce délai d'un mois aux vulnérabilités de haute gravité, mais la version 4.0.1 a rétabli une formulation plus restrictive. L'orientation de cette révision importe moins que le postulat sous-jacent : l'existence d'un correctif à installer.
S'il n'existe pas de correctif en amont pour votre branche, vous n'êtes pas en retard dans la correction. Vous êtes en dehors du modèle sur lequel l'exigence a été formulée, et il est plus difficile d'en discuter avec un évaluateur.
La norme SOC 2 n'interdit pas les logiciels en fin de vie ; soyez donc prudent dans votre communication interne. Elle invite surtout à s'interroger sur la gestion des vulnérabilités et votre capacité à démontrer une stratégie de remédiation efficace. Une dépendance non prise en charge, des vulnérabilités non identifiées et aucun correctif disponible sont susceptibles d'entraîner des demandes complémentaires, de ralentir les questionnaires de sécurité et de complexifier les évaluations des risques clients lors du renouvellement.
Vos options lorsque le support expire
Il y en a trois, et la bonne dépend moins de la CVE qui vous a signalée que de la surface Werkzeug réellement présente dans votre application.
Mise à niveau vers le dernier Werkzeug
La réponse classique, et pour de nombreuses équipes la bonne. Werkzeug 3.1.x est une version mature, son API est plus claire et les annotations de type sont réellement utiles.
Ce qui est intéressant, c'est l'hypothèse selon laquelle il s'agirait d'une modification d'une seule ligne. Werkzeug ne se met pas à jour automatiquement. Les versions de Flask indiquent généralement une version minimale de Werkzeug plutôt que de fixer une limite supérieure, ce qui permet à pip de résoudre une version de Werkzeug plus récente que celle avec laquelle votre version de Flask a été testée. Ce n'est pas une hypothèse. Werkzeug 3.0 a été supprimé. url_quote, que Flask 2.2.2 importe en haut de app.pyL'appairage échoue donc à l'importation. Werkzeug 3.1 a ensuite été supprimé. werkzeug.__version__Ce paramètre est toujours lu par le client de test Flask 2.2.4 lors de la construction de la chaîne d'agent utilisateur, ce qui provoque une erreur AttributeError lors de la première exécution de la suite de tests dans un conteneur vierge. Ce problème est décrit dans [référence manquante]. Flask numéro 5652.
La mise à jour de Werkzeug peut donc impliquer la mise à jour de Flask, ce qui nécessite un audit de chaque extension dépendante de Flask et donc une analyse de compatibilité de l'ensemble des dépendances. Si votre base de code est réduite, votre liste d'extensions courte et votre couverture de tests satisfaisante, effectuez la mise à jour immédiatement et arrêtez votre lecture. En revanche, s'il s'agit d'une application mature avec une décennie de middleware accumulé, prévoyez un budget adapté.
Passer à un autre framework
Certaines équipes, face à une dépendance non prise en charge, décident que la solution se trouve ailleurs. Django est une option si vous recherchez une solution complète, FastAPI un framework d'API asynchrone basé sur Starlette, Starlette lui-même si vous souhaitez bénéficier de la boîte à outils ASGI sans les contraintes, et Bottle ou Falcon une solution plus légère. FastAPI, en particulier, bénéficie d'une forte dynamique, d'une conception axée sur l'asynchrone et d'une documentation OpenAPI générée gratuitement.
Aucun de ces outils ne remplace Werkzeug tel quel. La logique de routage, l'analyse des requêtes, le rendu des modèles, la pile d'intergiciels, la gestion des erreurs et la configuration du déploiement doivent être entièrement repensés. Pour une application nécessitant une migration Werkzeug significative, une migration correctement planifiée et testée devient un projet s'étalant sur plusieurs sprints ou trimestres, et non une simple opération de nettoyage. Lancez-vous dans cette migration parce que vous souhaitiez déjà être asynchrone, et non parce qu'un outil d'analyse vous a alerté un mardi.
Utilisez le support étendu et gagnez du temps.
La troisième option consiste à conserver votre version actuelle et à continuer de recevoir les correctifs de sécurité. Ainsi, vous ne dépendez plus de la personne qui publie la prochaine information et vous reprenez le contrôle de votre calendrier. Vous trouverez une explication détaillée de ce fonctionnement plus bas.
Le coût réel d'une mise à niveau précipitée
Imaginez une équipe SaaS de trente personnes à qui l'on demande de corriger une faille critique avant la fin de la période d'obtention de la certification SOC 2, dans trois semaines. La mise à niveau en elle-même n'est pas le plus difficile. Ce sont les conséquences qui le sont.
Des bugs non détectés par les tests commencent à apparaître en production, et le support reçoit de nombreux tickets concernant des comportements auparavant normaux. Les dépendances transitives introduisent leurs propres cas limites, qui n'apparaissent qu'en situation de charge réelle, provoquant des pannes intermittentes extrêmement difficiles à reproduire et encore plus à expliquer lors d'un audit.
Puis, les raccourcis commencent. Les refactorisations sont ignorées, les solutions de contournement s'accumulent et tout le monde s'accorde à corriger le problème correctement plus tard. Six mois plus tard, ce « plus tard » n'est toujours pas arrivé et le code est dans un état pire qu'avant la mise à jour censée le remettre en état.
Les coûts suivent le même schéma : heures supplémentaires non budgétées, engagements pris dans le cadre de la feuille de route et ingénieurs seniors passant leur semaine à analyser la sortie du résolveur pip au lieu de développer les fonctionnalités demandées par les clients. Rien de tout cela n'apparaît dans le devis initial, car celui-ci concernait la mise à jour de version.
Comment fonctionne TuxCare ELS pour Werkzeug
Depuis 15 ans, TuxCare assure la maintenance des logiciels libres en fin de vie, avec plus de 420 000 correctifs déployés et plus de 14 000 vulnérabilités corrigées dans les systèmes d'exploitation, les environnements d'exécution, les bibliothèques et les applications. Werkzeug est pris en charge par le programme ELS pour bibliothèques de TuxCare.
Les versions couvertes incluent actuellement Werkzeug 1.0.1, 2.2.3 et 2.3.8, d'autres versions étant disponibles sur demande.
Qu'est-ce qui rend cette approche différente ?
La surface de dépendances de Werkzeug est exceptionnellement réduite. Les versions 2.x déclarent une seule dépendance d'exécution requise, MarkupSafe, et la version 1.0.1 n'en déclare aucune, ce qui simplifie la question de la couverture. ELS inclut des correctifs de sécurité pour les dépendances directes et transitives sans frais supplémentaires, ce qui est plus important qu'il n'y paraît, car les risques liés à la fin de vie peuvent se situer à un niveau inférieur à celui du paquet que vous suivez.
Le processus de correctifs est automatisé et vérifié manuellement. TuxCare surveille les CVE 24 h/24 et 7 j/7 dans le NVD, les avis des fournisseurs et les avis de sécurité GitHub, intègre les correctifs amont grâce à une automatisation algorithmique et assistée par IA, validée par des experts, puis soumet chaque version à des tests d'intégrité, de fonctionnalité et de régression avant de la signer et de la publier dans les dépôts ELS. Pour plus de détails, consultez la documentation sur le processus de correctifs open source .
L'intégration reste au sein de pip. Vous pouvez soit indiquer à pip l'emplacement du dépôt TuxCare avec index-url, ou vous conservez un PyPI public et l'ajoutez en tant que extra-index-url, en épinglant directement la version corrigée. Les versions corrigées comportent une chaîne de version comme werkzeug==1.0.1.post1+tuxcareAinsi, la version corrigée reste identifiable quel que soit l'endroit où vos versions résolues sont enregistrées. Il s'agit d'une modification de la configuration du dépôt nécessitant des identifiants, et non d'une reconstruction de votre pipeline de déploiement.
La livraison est garantie par un SLA et non par le principe du « au mieux ». Les paquets sont signés et distribués depuis des dépôts hébergés par TuxCare, avec une assistance 24h/24 et 7j/7 pour le tri et les demandes de correctifs nécessitant une intervention humaine. Pour les audits, chaque version corrigée inclut les données SBOM et un flux VEX, permettant ainsi aux outils compatibles VEX de distinguer les anomalies résolues de celles nécessitant encore une action.
Concernant les coûts, il ne s'agit pas de dire que le support étendu est bon marché. Il s'agit plutôt de déplacer l'ingénierie de migration, les tests de compatibilité et les corrections de régression d'une situation d'urgence vers une phase planifiée, où les coûts sont justifiés.
Comment démarrer
Si vous souhaitez savoir à quoi ressemble réellement la couverture pour votre version, le traqueur CVE de TuxCare répertorie les vulnérabilités Werkzeug qui ont été corrigées, et la documentation ELS couvre en détail les versions prises en charge et les options d'installation.
Pour connaître les versions prises en charge, les tarifs et le fonctionnement pratique de la mise en œuvre, la page d'assistance Endless Lifecycle pour Werkzeug est le point de départ.
Ne laissez pas un outil non pris en charge mettre vos systèmes en danger.
Le fait que Werkzeug soit la couche WSGI sous Flask implique que les décisions relatives à son cycle de vie sont rarement documentées. Lorsqu'une version non prise en charge contient une faille dans le code utilisé par votre application, cette dernière en est également affectée, et vous ne le découvrez que par un outil d'analyse ou un questionnaire, plutôt que par une note de version.
Pas de panique ! Vous pouvez planifier une mise à niveau de Werkzeug sur un trimestre où vous aurez le temps de bien la réaliser. Vous pouvez passer à un autre framework s’il existe une raison technique valable, au-delà du simple scan. Vous pouvez aussi continuer à recevoir les correctifs pour la version actuelle le temps de prendre votre décision. Cela vous permet de maintenir votre niveau de sécurité et de fournir des preuves concrètes de correction lors des audits de conformité, sans pour autant dévoiler votre feuille de route à quiconque signale la prochaine vulnérabilité.
Les équipes qui réussissent le mieux sont rarement celles qui disposent des plus gros budgets. Ce sont celles qui ont déterminé la version qu'elles utilisaient, compris ce qui était maintenu et ce qui ne l'était plus, et qui ont fait des choix réfléchis plutôt que de réagir impulsivement.
Si vous êtes confronté à l'un de ces problèmes actuellement, le support de cycle de vie illimité pour les logiciels libres montre comment un support étendu couvre les composants en fin de vie du reste de votre infrastructure aussi longtemps que nécessaire.
