Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
La fin de vie (EOL) de MySQL est l'un des événements les plus déterminants et les plus souvent reportés dans la gestion des bases de données d'entreprise. MySQL est au cœur des plateformes de commerce électronique, des applications SaaS, des systèmes de gestion de contenu, des outils internes et des pipelines de données dans pratiquement tous les secteurs d'activité. C'est précisément cette omniprésence qui rend la gestion de son cycle de vie si cruciale, et si facile à remettre à plus tard jusqu'à ce qu'elle devienne urgente.
Mais les versions de MySQL ne vieillissent pas bien d'elles-mêmes. Chacune dispose d'une période de support définie, et lorsque celle-ci prend fin, Oracle cesse de publier des correctifs de sécurité pour cette version. Toutes les vulnérabilités CVE divulguées après cette date s'appliquent à votre version, mais aucun correctif ne le fait. Si vous utilisez MySQL 5.7, la fin de vie (EOL) de MySQL est prévue pour octobre 2023. Si vous utilisez MySQL 8.0, elle est prévue pour avril 2026, et cette date est plus proche que ne le pensent la plupart des équipes.
Cet article explique le fonctionnement concret du cycle de vie des versions de MySQL, ce que signifie la fin de vie (EOL) de MySQL en termes de sécurité et de conformité, et quelles sont vos options lorsque vous ne pouvez pas simplement programmer une mise à niveau pour le prochain sprint.
Principaux enseignements
- Les dépendances multiplient les risques liés à la fin de vie (EOL) de MySQL : MySQL intègre des bibliothèques C tierces telles que OpenSSL, curl, LZ4, zlib et d'autres, chacune présentant ses propres vulnérabilités CVE qui ne sont plus corrigées une fois que la version de MySQL arrive en fin de vie.
- Les mises à niveau précipitées coûtent cher : Les mises à niveau majeures de MySQL impliquent la vérification de la compatibilité des schémas, le test des requêtes des applications, la reconfiguration de la réplication et le déploiement coordonné sur l'ensemble du parc. Le coût technique d'une migration imprévue est rarement négligeable.
- La fin de vie de MySQL ne signifie pas la fin de la sécurité. Le service Endless Lifecycle Support (ELS) de TuxCare fournit des correctifs continus pour les versions de MySQL qui ne sont plus prises en charge, couvrant l'ensemble des dépendances, afin que votre infrastructure de base de données reste protégée pendant que vous effectuez la mise à niveau selon votre propre calendrier.
En quoi consiste le cycle de vie des produits MySQL ?
Le cycle de vie de MySQL suit la politique de support à vie d'Oracle, qui définit trois phases distinctes pour chaque version majeure :
- Assistance Premier 5 ans à compter de la date de mise à disposition générale. Au cours de cette phase, Oracle fournit régulièrement, tous les trimestres, de nouvelles fonctionnalités, des corrections de bogues, des alertes de sécurité et des mises à jour de correctifs critiques via son programme Critical Patch Update (CPU).
- Assistance prolongée 3 ans après la fin du support Premier, moyennant des frais supplémentaires. Les alertes de sécurité et les mises à jour de correctifs critiques sont maintenues, mais aucune nouvelle fonctionnalité ni correction de bogues généraux n'est fournie.
- Assistance de maintenance Disponible après la fin du support étendu, pour une durée illimitée. Il est important de noter que cette phase ne prévoit aucune nouvelle version, aucune nouvelle correction de bogues et aucun nouveau correctif de sécurité. Seuls les correctifs existants restent accessibles.
Lorsque la communauté des développeurs de bases de données évoque la fin de vie d'une version de MySQL, cela signifie soit que cette version n'est plus couverte par le support étendu, soit, comme c'est le cas pour MySQL 5.7, qu'Oracle l'a transférée vers le support de maintenance, ce qui, concrètement, signifie qu'aucun nouveau correctif de sécurité ne sera publié à partir de ce moment-là.
En 2023, MySQL a mis en place un modèle de publication à deux volets afin d'offrir aux entreprises une meilleure prévisibilité du cycle de vie à l'avenir :
- Les versions à support à long terme (LTS) sont conçues pour assurer la stabilité en production. Chaque version LTS bénéficie de 5 ans de support Premier et de 3 ans de support étendu. MySQL 8.4 est la version LTS actuelle.
- Versions « Innovation » Versions trimestrielles proposant les dernières fonctionnalités. Chaque version Innovation n'est prise en charge que jusqu'à la sortie de la suivante, ce qui la rend inadaptée aux environnements de production nécessitant des fenêtres de mise à jour prévisibles.
| Version de MySQL | Statut | Remarques |
| 5.7 | Fin de vie en octobre 2023 | Assistance de maintenance uniquement – aucun nouveau correctif de sécurité |
| 8.0 | Fin de vie : avril 2026 | Fin du support étendu : plus aucun correctif après avril 2026 |
| 8.4 LTS | Prise en charge | Assistance Premier pour la version LTS actuelle jusqu'en 2029 environ |
| 9.x (Innovation) | Roulement | Chaque publication est remplacée par la publication trimestrielle suivante |
En résumé : si votre parc utilise MySQL 5.7, vous fonctionnez sans correctifs de sécurité en amont depuis octobre 2023. S'il utilise MySQL 8.0, le compte à rebours a déjà commencé en vue de la fin de vie (EOL) de MySQL prévue en avril 2026.
Que signifie la fin de vie de MySQL ?
Fin des correctifs de sécurité
Lorsqu'une version de MySQL passe en phase de support de maintenance, Oracle cesse de développer des correctifs de sécurité pour celle-ci. Cela signifie que toute vulnérabilité découverte à partir de ce moment-là dans les composants principaux de MySQL, dans son optimiseur de requêtes, dans son système de réplication ou dans ses bibliothèques intégrées fera l'objet d'un correctif pour les versions prises en charge, mais pas pour la vôtre.
Voici la réalité fondamentale en matière de sécurité lorsqu'on utilise à grande échelle des logiciels dont le support a pris fin : la communauté des chercheurs en vulnérabilités et l'équipe de sécurité d'Oracle continuent de découvrir et de divulguer des failles de manière constante. Le cycle trimestriel de mises à jour critiques (Critical Patch Update), qui fournissait auparavant des correctifs pour votre version, ne s'applique tout simplement plus à celle-ci. Votre exposition aux risques s'accroît à chaque cycle de mise à jour qui s'écoule sans que votre version ne soit prise en compte.
Risques liés à la sécurité et à la conformité après la fin de vie de MySQL
La situation en matière de conformité est tout aussi claire. La norme PCI DSS (exigence 6.3.3) impose que les vulnérabilités critiques et de gravité élevée, dont le score CVSS est égal ou supérieur à 7,0, soient corrigées dans un délai d'un mois à compter de la publication du correctif pour les systèmes concernés. Les normes HIPAA, FedRAMP et SOC 2 contiennent des exigences comparables pour les environnements qu'elles régissent. Utiliser une version de MySQL hors support dans un environnement réglementé revient à exploiter une base de données que vous ne pouvez pas corriger dans les délais imposés par ces référentiels, ce qui crée une lacune de conformité que les contrôles compensatoires ne peuvent combler que partiellement.
Le fait que MySQL serve de base de données pour les charges de travail des applications contenant des dossiers clients, des transactions financières, des identifiants d'authentification et des données stratégiques en fait une cible prioritaire pour tout pirate informatique qui repère un déploiement non corrigé fonctionnant sur une version dont le support a pris fin.
Historique des vulnérabilités CVE de MySQL
Le dossier CVE de MySQL illustre concrètement à quoi ressemble l'exposition aux risques après la fin de vie d'un produit.
CVE-2023-21980 CVSS 7.1 Élevé. Cette vulnérabilité affectait le composant des programmes clients de MySQL Server dans les versions 5.7.41 et antérieures, ainsi que 8.0.32 et antérieures. Un attaquant disposant de privilèges limités et d'un accès au réseau pouvait exploiter cette faille pour prendre le contrôle total du serveur MySQL, compromettant simultanément la confidentialité, l'intégrité et la disponibilité. Oracle a publié des correctifs pour les versions prises en charge dans le cadre de la mise à jour critique d'avril 2023. Tout déploiement exécutant MySQL 5.7 après la date de fin de vie (EOL) d'octobre 2023 n'a reçu aucune solution de correction de la part d'Oracle par la suite ; le correctif existait, mais uniquement pour les versions prises en charge. C'est là le schéma caractéristique de l'exposition liée à la fin de vie de MySQL : des correctifs sont publiés pour les versions prises en charge, tandis que les déploiements en fin de vie accumulent des CVE non résolues sans correctif en amont disponible.
Ce qui rend cette tendance particulièrement préoccupante, c'est son ampleur. Les rapports trimestriels d'Oracle font régulièrement état de dizaines de vulnérabilités MySQL touchant divers composants, notamment InnoDB, l'optimiseur, la réplication, le DDL, les programmes clients, etc. Chaque trimestre qui s'écoule après la fin de vie (EOL) de MySQL représente une série de correctifs dont votre déploiement ne bénéficiera jamais. L'exposition cumulative s'accroît donc à chaque trimestre.
Le problème de la surface de dépendance
MySQL n'est pas un binaire autonome ; il s'agit d'un serveur compilé qui intègre un ensemble important de bibliothèques C tierces, chacune présentant ses propres failles de sécurité. Lors de sa distribution, MySQL intègre ou associe des bibliothèques telles que OpenSSL pour le chiffrement TLS, curl pour les opérations HTTP, LZ4 pour la compression, zlib pour la compression générale des données et libevent pour la gestion des événements réseau, entre autres.
Chacune de ces bibliothèques intégrées dispose de son propre historique CVE et suit son propre calendrier de publication. La mise à jour trimestrielle « Critical Patch Update » d'Oracle corrige les vulnérabilités de ces composants intégrés : elle met à niveau la version d'OpenSSL fournie avec MySQL lorsqu'une vulnérabilité TLS critique est révélée, ou corrige le composant curl intégré lorsqu'une faille de gestion du réseau est détectée.
Une fois MySQL arrivé en fin de vie (EOL), aucune de ces mises à jour des bibliothèques intégrées ne sera non plus appliquée à votre version. Une vulnérabilité critique d'OpenSSL, une faille de corruption de mémoire dans curl et un débordement de tampon dans LZ4 : toutes ces failles seront corrigées dans les versions de MySQL encore prises en charge, mais aucune ne le sera dans la vôtre. La surface d'exposition aux risques ne se limite pas au code de traitement des requêtes propre à MySQL ; elle s'étend à toutes les bibliothèques que MySQL a intégrées.
Ce phénomène était observable tout au long de la durée de vie de MySQL 5.7 : les avis de correctifs de Tenable concernant les versions de MySQL 5.7 mentionnaient systématiquement des CVE dans des composants intégrés tels que curl (CVE-2021-22901, une vulnérabilité de type « use-after-free » pouvant permettre une exécution de code à distance), LZ4 (CVE-2019-17543, un débordement de pile) et OpenSSL (CVE-2021-3711, un débordement de tampon pouvant entraîner la prise de contrôle du serveur) comme des vulnérabilités corrigées par les versions de correctifs MySQL, démontrant ainsi à quel point l'exposition des bibliothèques intégrées est profondément ancrée dans la surface d'attaque de MySQL. Une fois que MySQL atteindra sa fin de vie (EOL), toutes ces voies de correction seront fermées.
Solutions pour garantir la sécurité et la conformité après la fin de vie de MySQL
Passez à une version prise en charge de MySQL
La migration vers MySQL 8.4 LTS est la stratégie à long terme recommandée pour toute organisation qui utilise encore MySQL 5.7 ou qui souhaite anticiper la fin de vie de MySQL 8.0, prévue en avril 2026. MySQL 8.4 LTS est la version actuelle d'Oracle destinée à la production et bénéficiant d'un support à long terme, couverte par le support Premier Support jusqu'en 2029 environ.
La complexité de cette migration dépend fortement de votre environnement. La mise à niveau d'un parc de serveurs MySQL ne se fait pas de la même manière qu'une simple instance de développement : elle nécessite des déploiements coordonnés avec un contrôle des changements, des déploiements par étapes entre les équipes applicatives, la validation de la compatibilité des schémas avec les couches ORM et les requêtes applicatives, la reconfiguration des topologies de réplication, ainsi que des tests dans des environnements de préproduction reflétant l'environnement de production. Pour les organisations utilisant MySQL 5.7 et effectuant une mise à niveau directe vers la version 8.4, l'écart couvre deux versions majeures, ce qui implique une surface de compatibilité supplémentaire à vérifier.
Passer à une autre base de données
Certaines organisations profitent de la fin de vie (EOL) de MySQL pour envisager des alternatives, telles que PostgreSQL, MariaDB ou des services de bases de données gérés dans le cloud qui prennent en charge la gestion du cycle de vie des versions. Il s'agit là de choix réellement viables à long terme pour certains environnements, mais il s'agit de projets d'ingénierie s'étalant sur plusieurs trimestres, et non de solutions destinées à répondre à une échéance de mise à jour.
Pour la plupart des organisations confrontées à une date de fin de vie imminente, la migration vers une nouvelle plateforme ne constitue pas une solution réaliste pour combler les lacunes immédiates en matière de sécurité et de conformité.
Vous pouvez également découvrir ce que signifie la fin de vie (EOL) de MariaDB 10.6 pour les équipes qui envisagent cette voie dans notre guide détaillé.
La solution recommandée : le support à vie TuxCare pour MySQL
Le service « Endless Lifecycle Support » (ELS) de TuxCare pour MySQL résout directement les problèmes de sécurité et de conformité liés à la fin de vie (EOL) de MySQL, sans nécessiter de migration immédiate vers une version majeure. TuxCare fournit en continu des correctifs de sécurité pour les versions de MySQL qui ne sont plus prises en charge, couvrant à la fois les composants propres à MySQL et les bibliothèques tierces associées, sans frais supplémentaires. Cela permet à votre parc de bases de données de conserver un niveau de sécurité défendable pendant que vous planifiez la mise à niveau que vous souhaitez réellement effectuer.
Le fonctionnement est simple : TuxCare surveille le NVD, les avis de sécurité d'Oracle et les flux de sécurité des bibliothèques en amont afin de détecter les vulnérabilités affectant MySQL et ses composants intégrés, puis rétroporte et fournit des correctifs pour les versions en fin de vie (EOL) via des processus couverts par un contrat de niveau de service (SLA). Votre version de MySQL continue de fonctionner. Votre conformité est maintenue. Et vous restez maître de votre calendrier de mise à niveau.
Les risques liés à une mise à niveau précipitée de MySQL
Lorsque les dates de fin de vie (EOL) de MySQL approchent, la pression pour réagir immédiatement est bien réelle, mais le coût d'une mauvaise réaction est plus élevé que ne le prévoient la plupart des équipes.
En quoi consiste réellement une mise à niveau de MySQL ?
Une mise à niveau vers une version majeure de MySQL, en particulier de la version 5.7 à la version 8.4 sur l'ensemble d'un parc de serveurs de production, ne se fait pas par redémarrage progressif. Elle implique une adaptation du code pour toutes les requêtes d'application, les procédures stockées ou le SQL généré par ORM qui s'appuient sur une syntaxe ou un comportement ayant changé d'une version à l'autre. Cela implique une vérification de la compatibilité pour chaque bibliothèque cliente de base de données, connecteur et version ORM utilisés par votre pile d'applications, car les matrices de prise en charge des versions pour des frameworks tels que Django, Rails, Hibernate et autres doivent être validées par rapport à la version cible de MySQL. Cela implique l'adaptation de la chaîne d'outils des pipelines de sauvegarde, des exportateurs de surveillance et des outils de migration de bases de données qui s'intègrent directement aux composants internes de MySQL. Et cela implique une charge de travail supplémentaire liée aux tests des plans de requêtes, des changements entre les versions de l'optimiseur, des modifications du comportement des index et des cas limites dans les requêtes d'application qui n'apparaissent que sous charge dans des conditions proches de la production.
Dans un parc informatique d'entreprise comptant des centaines, voire des milliers de serveurs de bases de données, avec des dépendances applicatives hétérogènes, des fenêtres de mise à jour régies par des processus de contrôle des changements et des dépendances de services nécessitant une validation coordonnée, il s'agit d'un programme de travail coordonné, et non d'une migration réalisable en un week-end.
Que se passe-t-il quand la mise à jour est précipitée ?
Lorsque les équipes sont contraintes de procéder à une mise à niveau de MySQL en raison d'une échéance de conformité plutôt que d'une préparation suffisante, le scénario qui s'ensuit est toujours le même. La charge de support augmente considérablement à mesure que les équipes applicatives découvrent des problèmes de compatibilité des requêtes qui n'avaient pas été détectés lors de la phase de préproduction. L'instabilité du système se manifeste par des retards de réplication, un comportement inattendu des index ou des régressions dans les plans de requêtes qui affectent la latence en production. La dette technique s'accumule à mesure que des solutions de contournement sont déployées pour respecter l'échéance, ce qui engendre des retouches qui devront être traitées lors des sprints suivants. Et les coûts imprévus s'alourdissent en termes de temps d'ingénierie, de perturbations potentielles du service et de frais généraux liés à la gestion d'une migration dont la portée n'avait pas été correctement définie avant son lancement.
Les organisations qui gèrent efficacement les transitions liées à la fin de vie (EOL) de MySQL les considèrent comme des migrations planifiées, avec un périmètre bien défini, un délai de test suffisant et un niveau de sécurité stable maintenu tout au long du processus, et non comme des interventions d'urgence face à une échéance à laquelle elles n'étaient pas préparées.
La solution simple : TuxCare ELS pour MySQL
Depuis plus de dix ans, TuxCare perfectionne ses systèmes d'automatisation, son expertise et ses processus afin de fournir de manière fiable et à grande échelle des correctifs de sécurité pour les logiciels en fin de vie. Avec plus de 220 000 correctifs déployés sur l'ensemble de son portefeuille de produits pris en charge, TuxCare a mis au point un processus de correction à la fois rapide et sans risque pour l'environnement de production.
En ce qui concerne spécifiquement MySQL, l'ELS de TuxCare comble la faille de sécurité engendrée par la fin de vie (EOL) de MySQL :
- Correctifs de sécurité rapides, couverts par un SLA. TuxCare surveille en permanence les divulgations de vulnérabilités et fournit des correctifs pour les CVE à risque élevé et critique (CVSS 7.0+) selon des SLA définis, garantissant ainsi que vos déploiements MySQL respectent les délais de correction exigés par les normes PCI DSS, HIPAA, FedRAMP et autres cadres de conformité.
- Couverture complète de la surface de dépendance: TuxCare couvre à la fois la surface de vulnérabilité propre à MySQL et les bibliothèques tierces intégrées OpenSSL, curl, LZ4 et autres, sans frais supplémentaires. L'exposition cachée à la fin de vie (EOL) dans les dépendances compilées de MySQL ne devient pas votre problème.
- Intégration transparente à vos flux de travail existants. Que vous gériez actuellement les mises à jour MySQL via des gestionnaires de paquets, des outils de gestion de configuration ou vos pipelines CI/CD existants, vous pouvez basculer votre source de mise à jour vers le référentiel sécurisé de TuxCare avec un minimum de modifications de votre flux de travail actuel. Cela n'entraîne aucune perturbation de votre chaîne d'outils actuelle.
- Paquets signés et inviolables. Chaque correctif fourni par TuxCare fait l'objet de tests approfondis portant sur son intégrité, sa fonctionnalité et la régression avant d'atteindre votre référentiel, et les paquets sont signés cryptographiquement afin que vous sachiez exactement ce que vous déployez.
- Assistance spécialisée 24 h/24, 7 j/7 L'équipe de sécurité de TuxCare est disponible 24 heures sur 24 pour le triage des vulnérabilités, les demandes de correctifs et le dépannage. Vous ne vous retrouverez donc jamais à gérer un incident de sécurité lié à la fin de vie (EOL) de MySQL sans l'aide d'un spécialiste.
Pour savoir quelles vulnérabilités CVE de MySQL ont déjà été corrigées, TuxCare met à jour un suivi en temps réel des CVE. Pour plus de détails sur le processus de correction et les normes de validation de TuxCare, consultez le livre blanc technique.
Ne laissez pas la fin de vie de MySQL mettre en péril votre infrastructure de bases de données
La fin de vie (EOL) de MySQL ne signifie pas que vos bases de données sont immédiatement compromises. Cela signifie toutefois que la protection sur laquelle reposait votre infrastructure n'existe plus, et que chaque vulnérabilité CVE publiée à partir de ce moment-là constitue une faille de sécurité à laquelle vous êtes exposé, sans possibilité de correction en amont.
Les équipes qui gèrent efficacement cette situation sont celles qui considèrent la fin de vie (EOL) de MySQL comme un enjeu de sécurité à gérer de manière réfléchie, et non comme une échéance à respecter sous la pression. Vous pouvez planifier une migration réfléchie vers MySQL 8.4 LTS lorsque cela correspond véritablement à la capacité de votre parc, à l'état de préparation de vos équipes d'application et aux processus de gestion du changement de votre organisation. Vous pouvez définir correctement le périmètre de la migration avant de vous engager sur un calendrier. Vous pouvez également utiliser TuxCare ELS pour maintenir la sécurité et la conformité pendant que vous prenez ces décisions selon vos propres conditions, et non selon le calendrier imposé par un audit de conformité.
ELS for MySQL n'est pas une solution de secours. C'est la solution qui garantit la sécurité de votre parc de bases de données, le respect de vos obligations de conformité et permet à vos équipes d'ingénieurs de se concentrer sur le développement plutôt que sur la gestion de migrations d'urgence.
Si la fin de vie de MySQL figure actuellement parmi vos priorités en matière de sécurité, rendez-vous sur le support à cycle de vie illimité de TuxCare pour les logiciels open source pour découvrir comment une assistance prolongée peut protéger votre infrastructure de bases de données aussi longtemps que vous le souhaitez.
