MariaDB 10.6 arrivera en fin de vie le 6 juillet 2026 : ce que cela signifie et comment assurer la sécurité de vos systèmes

Principaux enseignements

• MariaDB Community Server 10.6 arrivera en fin de vie le 6 juillet 2026. Après cette date, le projet MariaDB cessera de fournir des correctifs de sécurité et des corrections de bogues pour la version 10.6.
• L'exploitation d'une base de données non mise à jour en environnement de production constitue un problème de sécurité et de conformité. Les normes PCI DSS, HIPAA, SOC 2 et FedRAMP exigent toutes que les vulnérabilités connues soient corrigées dans les meilleurs délais.
• Passer à la version 11.4 ou 11.8 LTS est la bonne décision à long terme lorsque cela peut se faire sans heurts. Lorsque les délais sont serrés, le support à cycle de vie illimité de TuxCare pour MariaDB maintient la version 10.6 à jour grâce aux correctifs, ce qui vous permet de procéder à la mise à niveau selon votre propre calendrier.

Si vous utilisez MariaDB Community Server 10.6 en production, notez bien cette date dans votre agenda : le 6 juillet 2026. C'est à cette date que la branche 10.6 arrivera en fin de vie et que le projet MariaDB la clôturera. Après cela, le projet cessera de publier des versions, des corrections de bogues et des correctifs de sécurité pour cette branche.

Après le 6 juillet, votre base de données continuera à traiter les requêtes exactement comme elle le faisait la veille. Le problème réside dans ce qui se passe en coulisses au cours des mois suivants : de nouvelles vulnérabilités sont découvertes et ne sont jamais corrigées, les auditeurs commencent à poser des questions, et l'écosystème autour de la version 10.6 évolue discrètement.

Cet article aborde le calendrier de la version 10.6, les changements concrets que la fin de vie implique pour votre environnement, ainsi que les options réalistes qui s'offrent à vous. Si vous cherchez une réponse rapide du type « il suffit de mettre à jour, tout ira bien », vous n'êtes pas au bon endroit. La mise à jour d'une base de données en production est rarement aussi simple qu'elle en a l'air vue de l'extérieur, et notre objectif ici est de vous aider à choisir la voie la mieux adaptée à votre situation.

Figure 1. Versions LTS de MariaDB et dates de fin de vie fixées par la communauté. La version 10.6 est la prochaine à arriver à échéance.

Les versions et le cycle de vie de MariaDB, en bref

MariaDB propose deux types de versions. Les versions « rolling » sont publiées environ tous les trimestres et ne sont prises en charge que jusqu'à la version suivante. Les versions à support à long terme (LTS) sont publiées environ une fois par an et bénéficient d'une période de maintenance plus longue, avec des corrections de bogues et de sécurité. Les systèmes de production doivent utiliser une version LTS.

MariaDB 10.6 est une version LTS. Elle a été lancée le 6 juillet 2021 avec une période de maintenance de cinq ans, ce qui fixe sa fin de vie au 6 juillet 2026. Depuis, MariaDB a fait passer Community Server à un modèle LTS annuel avec une période de maintenance de trois ans, à compter de la version 11.8 (la version 11.4 reste une version LTS de cinq ans). Voici où en sont les versions LTS récentes à la date de juin 2026 :

Deux points méritent d'être soulignés. Premièrement, les versions 10.4 et 10.5 ont déjà atteint leur fin de vie, et la version 10.6 sera la prochaine sur la liste ; ainsi, la plupart des versions de la gamme 10.x n'ont plus de support – la version 10.11 LTS, prise en charge jusqu'en février 2028, en est la seule exception.  Deuxièmement, les versions LTS prises en charge sont la 10.11 (jusqu'en février 2028), la 11.4 (jusqu'en mai 2029), la 11.8 (jusqu'en juin 2028) et la 12.3 (la version LTS la plus récente, jusqu'en 2029). Pour les équipes qui abandonnent la version 10.6, la version 10.11 est la version la plus compatible mais dont la durée de vie est la plus courte, tandis que les versions 11.4 et 12.3 offrent la prise en charge la plus longue et sont celles qui font l'objet de la plupart des discussions sur la mise à niveau.

Que se passera-t-il après la fin de vie de MariaDB 10.6 ?

La fin de vie signifie que tout travail de maintenance prend fin. Pour MariaDB 10.6, cela engendre trois problèmes qui s'aggravent avec le temps :

1. La distribution des correctifs de sécurité est suspendue

C'est là que réside le véritable danger. Après le 6 juillet 2026, les failles affectant MariaDB Community Server ne seront corrigées que dans les branches communautaires prises en charge, tandis que la version 10.6 de Community Server ne bénéficiera plus de ces correctifs. Le moteur de base de données est une cible de choix – il héberge les données et est souvent accessible depuis les serveurs d'applications – et une seule faille peut exposer tout ce qui se trouve derrière.

Le schéma d'exploitation des versions en fin de vie est bien connu. Lorsqu'un projet publie un correctif pour une version prise en charge, celui-ci est rendu public ; les pirates peuvent donc voir exactement quel code a été modifié et en déduire la nature du bug sous-jacent. Ils recherchent ensuite cette même faille dans les versions en fin de vie qui ne bénéficieront jamais de correctifs. L'automatisation et l'analyse assistée par l'IA peuvent accélérer ce processus de rétro-ingénierie, ce qui réduit considérablement le délai entre la publication d'un correctif et la mise au point d'un exploit fonctionnel. Une base de données EOL est exactement le type de cible que ce schéma favorise. 

2. Les risques liés à la conformité et à l'audit augmentent

La plupart des cadres de sécurité exigent l'application rapide de correctifs pour les problèmes connus. L'exigence 6 de la norme PCI DSS impose aux organisations d'identifier les vulnérabilités, de les classer par niveau de risque et d'y remédier, en installant les correctifs critiques et à haut niveau de gravité dans un délai d'un mois à compter de leur publication (6.3.3 dans la version 4.0.1). Les auditeurs SOC 2 peuvent signaler les composants non pris en charge lorsqu'ils créent un risque non résolu en matière de gestion des vulnérabilités ou de gestion des changements. Dans les environnements réglementés par la loi HIPAA, les logiciels non pris en charge peuvent soulever des questions quant au caractère raisonnable des mesures de protection techniques et des pratiques de gestion des risques. Le programme FedRAMP et les régimes similaires exigent une mise à jour continue des correctifs, accompagnée d'une documentation correspondante.

Ce qui est frustrant, c'est que la base de données peut être le seul composant en fin de vie (EOL) d'une infrastructure par ailleurs irréprochable, tout en donnant lieu à une non-conformité lors d'un audit. Les examens menés dans le cadre des assurances cyber peuvent également se pencher sur les logiciels non pris en charge, en particulier lorsqu'un incident ou un processus de renouvellement met en évidence des lacunes dans la gestion des correctifs et des vulnérabilités.

3. L'écosystème s'éloigne

Une fois qu'une version atteint sa fin de vie (EOL), les logiciels qui l'utilisent cessent progressivement de la prendre en charge. Au fil du temps, les distributions Linux, les images de conteneurs et les référentiels tiers ont tendance à remplacer leurs paquets MariaDB par défaut par des versions plus récentes et prises en charge. Au bout de six mois, cela se traduit par une accumulation croissante de versions épinglées et de solutions de contournement, et la mise à niveau que vous repoussiez est discrètement devenue plus difficile, et non plus facile.

Figure 2. Les trois domaines de risque qui s'accumulent lorsqu'une base de données arrive en fin de vie.

Quelles sont vos options après la fin de vie de MariaDB 10.6 ?

Le choix de la solution la mieux adaptée dépend de l'importance stratégique de la base de données, de la charge opérationnelle que vous êtes prêt à assumer et de votre calendrier de mise à niveau réaliste. Quatre options méritent d'être envisagées.

Figure 3. Quatre options possibles après la fin de vie de MariaDB 10.6, avec les principaux compromis associés à chacune.

Option 1 : Passer à une version LTS prise en charge (10.11, 11.4, 11.8 ou 12.3)

C'est la solution classique et la bonne décision à prendre lorsque vous pouvez la mettre en œuvre sans heurts. Le passage à une version LTS prise en charge rétablit les correctifs de sécurité officiels et, selon la version ciblée, peut apporter des améliorations dans des domaines tels que l'optimiseur, la gestion du JSON, la réplication et les outils opérationnels. MariaDB assure généralement la compatibilité des protocoles client-serveur, mais le comportement des applications, la sémantique SQL, la réplication, le format du journal binaire, les versions des connecteurs et les paramètres de configuration doivent tout de même être testés avant une mise à niveau majeure.

Le problème est qu’un changement majeur de version sur une base de données en production nécessite de revoir le schéma et la configuration, de valider les topologies de réplication, de tester le comportement des applications avec la nouvelle version et de planifier une fenêtre d’indisponibilité ou de basculement. MariaDB 11.0 a introduit un nouveau modèle de coût pour l’optimiseur – et certaines requêtes peuvent devenir plus lentes – il est donc judicieux de tester votre charge de travail réelle sur une copie de préproduction afin de détecter tout changement dans le plan d’exécution avant qu’il n’atteigne la production. Une approche courante et moins risquée consiste à valider la version cible sur une réplique ou une copie de test restaurée en conditions de trafic réel, puis à planifier la bascule et le chemin de retour en arrière avant de la déployer. La stratégie exacte de réplication et de déploiement dépend de votre topologie et du nombre de versions majeures que le saut implique ; vérifiez donc d'abord le chemin de mise à niveau pris en charge. 

Option 2 : Passer à MariaDB Enterprise Server

MariaDB plc commercialise une version Enterprise Server de la version 10.6, dont le support est assuré jusqu'au 23 août 2029, soit environ trois ans après la date limite fixée par la communauté. Comme elle reste dans la série 10.6, cette évolution s'apparente davantage à un changement de distribution qu'à une mise à niveau vers une version majeure, et elle ajoute des fonctionnalités d'entreprise ainsi qu'une assistance fournisseur.

Les inconvénients sont un abonnement payant coûteux, un certain degré de dépendance vis-à-vis du fournisseur et le passage d'une distribution communautaire à une distribution binaire différente. Pour les équipes qui ont spécifiquement besoin de MariaDB Enterprise Server 10.6, soutenu par le fournisseur et offrant une prise en charge de la conformité STIG, cela peut constituer une solution raisonnable. Pour les équipes dont l'objectif principal est de maintenir à jour leur déploiement open source existant, cela peut représenter un changement plus important que ne l'exige le problème.

Option 3 : Gestion autonome ou fork

En principe, vous pouvez utiliser le code source open source de la version 10.6, suivre vous-même les CVE et rétroporter les correctifs dans votre propre version. Dans la pratique, cela est difficile à maintenir. Le rétroportage des correctifs de sécurité des bases de données nécessite des ingénieurs capables de lire et de corriger correctement une base de code volumineuse en C et C++, de valider les correctifs, et ce, selon le calendrier dicté par l'apparition de nouvelles vulnérabilités plutôt que selon celui que vous auriez souhaité. La plupart des équipes ne peuvent pas disposer d'un personnel aussi fiable, et un effort mené avec des ressources insuffisantes est pire que l'absence de plan, car il crée un faux sentiment de couverture.

Option 4 : Sécurité étendue avec assistance tout au long du cycle de vie

C'est ce juste milieu pragmatique que les équipes ont tendance à sous-estimer. Le support à cycle de vie illimité de TuxCare pour MariaDB assure la mise à jour de votre déploiement 10.6 actuel contre les nouvelles vulnérabilités après la date de fin de vie fixée par la communauté. TuxCare suit les CVE dans MariaDB, rétroporte les correctifs vers votre version open source et les fournit sous forme de paquets de remplacement prêts à l'emploi via le gestionnaire de paquets que vous utilisez déjà. Aucune réécriture d'application n'est nécessaire, et l'objectif est de préserver les workflows de réplication et de sauvegarde existants avec un minimum de perturbations opérationnelles.

L'intérêt de cette option est de dissocier l'urgence en matière de sécurité des capacités techniques. Les correctifs continuent d'être publiés, l'application continue de fonctionner, et votre équipe procède aux mises à niveau selon un calendrier dicté par les contraintes techniques plutôt que par une date fixe. Cette solution est indiquée lorsque votre mise à niveau ne pourra pas, de manière réaliste, être achevée avant le 6 juillet 2026, lorsque vous avez des obligations de conformité qui exigent l'application continue et documentée de correctifs, ou lorsque le déploiement est stable et ne justifie tout simplement pas une mise à niveau majeure précipitée pour le moment.

Pourquoi la mise à niveau n'est pas toujours la solution immédiate

Sur le papier, la mise à niveau semble être la solution idéale. Dans la réalité, c'est plus compliqué, pour plusieurs raisons qu'on a tendance à sous-estimer.

Les dépendances et les intégrations constituent généralement les véritables obstacles. Le moteur MariaDB lui-même ralentit rarement les mises à niveau. Ce qui les ralentit, c'est le code de l'application, les procédures stockées, la configuration de la réplication et les outils associés, qui sont tous conçus pour fonctionner avec votre version actuelle. La résolution de ces problèmes prend du temps, ce que ne permet pas une date de fin de vie fixe.

Les mises à jour précipitées coûtent très cher. Elles génèrent des bogues, négligent les cas limites et rognent sur les tests. Le coût se répercute dès le trimestre suivant sous forme d'incidents et de charge de garde, et il dépasse souvent le coût d'une mise à niveau plus lente et planifiée, même en tenant compte du support prolongé.

Certains systèmes ne justifient pas un tel effort pour le moment. Une base de données sous-jacente à une application dont le remplacement est prévu, ou une base de données exécutant une charge de travail fixe sans projet de nouvelles fonctionnalités, ne justifie peut-être pas une mise à niveau majeure cette année. Pour ces systèmes, l'application de correctifs à la version actuelle jusqu'au changement prévu constitue un choix technique défendable plutôt qu'un raccourci.

Sécurisez MariaDB 10.6 sans mise à niveau, avec TuxCare

La date butoir pour MariaDB 10.6 est fixée au 6 juillet 2026. Passé cette date, le projet cessera de publier des correctifs, et chaque nouvelle vulnérabilité s'accumulera sur tous les serveurs fonctionnant encore sous la version 10.6. La mise à niveau vers une version LTS prise en charge (10.11, 11.4, 11.8 ou 12.3) est la solution idéale lorsque vous pouvez la réaliser proprement et dans un délai raisonnable. Lorsque ce n'est pas possible, parce que les dépendances ne sont pas prêtes, que le délai est trop court ou que le déploiement ne justifie pas la perturbation, le support étendu vous permet de rester en sécurité sans vous contraindre à une migration hasardeuse.

Le support à cycle de vie illimité de TuxCare pour MariaDB comble cette lacune grâce à des correctifs de sécurité continus, couverts par un SLA, pour les versions de MariaDB en fin de vie, fournis via votre gestionnaire de paquets existant sans aucune modification du code. Si vous souhaitez voir comment cela s'adapte à votre environnement, contactez un expert TuxCare. L'objectif est de vous donner le contrôle du calendrier de mise à niveau, et non de le remplacer.

Résumé

Nom de l'article

Fin de vie de MariaDB 10.6

Description

MariaDB 10.6 arrivera en fin de vie le 6 juillet 2026. Découvrez les risques liés à son utilisation sans correctifs et quatre moyens d'en garantir la sécurité : TuxCare ELS.

Auteur

Artem Karasev

Nom de l'éditeur

de TuxCare

Logo de l'éditeur