Des failles critiques affectant les composants principaux et les extensions de PostgreSQL et MariaDB pourraient permettre l’exécution de code à distance. Les bugs, certains vieux de plus de 20 ans, ont maintenant été corrigés.
Les bases de données open source sont confrontées à un problème de mémoire, car l’IA aide à faire ressortir des problèmes de dépassement de tampon vieux de plusieurs décennies dans des composants largement utilisés. Les chercheurs en sécurité ont révélé un ensemble de vulnérabilités de gravité élevée et critique affectant PostgreSQL et MariaDB, avec deux bugs dont les racines remonteraient à plus de 20 ans.
Lors de l’événement de piratage zeroday.cloud de Wiz, des chercheurs utilisant l’outil d’analyse de sécurité basé sur l’IA « Xint Code » ont découvert un bug zero-day de haute gravité dans l’extension « pgcrypto » de PostgreSQL et un débordement de tampon de tas dans la logique de validation de schéma JSON de MariaDB, tous deux permettant l’exécution de code à distance (RCE) sur les serveurs de base de données respectifs.
L’équipe Xint Code a également découvert un bug de validation manquant dans PostgreSQL, caché depuis 20 ans, permettant aux attaquants d’écrire du code arbitraire.
Des correctifs ont été publiés pour toutes ces failles, les responsables de PostgreSQL et de MariaDB exhortant les utilisateurs à mettre immédiatement à niveau vers les versions corrigées.
Plus d’une fissure dans les fondations de PostgreSQL
La faille zero-day la plus pressante de PostgreSQL est un problème de dépassement de tampon basé sur le tas, suivi comme CVE-2026-2005, dans l’extension « pgcrypto ». En utilisant des entrées spécialement conçues, un attaquant peut déclencher une inadéquation de taille qui conduit à des écritures hors limites sur le tas, ont indiqué les chercheurs dans un article de blog.
Dans les environnements où pgcrypto traite les entrées contrôlées par l’utilisateur, cela peut être exploité pour réaliser l’exécution de code à distance sur le serveur de base de données.
La faille affectait toutes les versions prises en charge et a été corrigée dans les mises à jour, notamment v18.2, v17.8, v16.12, v15.16 et v14.21. Il a reçu une note de gravité élevée de CVSS 8,8 sur 10. « Le code vulnérable est présent depuis la première contribution de pgcrypto en 2005, il y a plus de 20 ans », ont ajouté les chercheurs.
Ce n’était pas la seule faille signalée dans PostgreSQL. Un autre groupe de chercheurs concourant sous le nom de « Team Bugz Bunnies » lors de l’événement Wiz a trouvé un bug de validation manquant, suivi comme CVE-2026-2006, qui permet l’exécution de code arbitraire. La faille a été évaluée à une gravité CVSS proche de 9 et a été corrigée dans les mêmes mises à jour qui ont corrigé CVE-2026-2005.
Les responsables de PostgreSQL ont exhorté les clients à corriger rapidement les failles lorsqu’elles ont été rendues publiques après être passées inaperçues pendant des années, et que les attaquants ont accès au code d’exploitation. Les failles ont été corrigées en février, mais une analyse Wiz a révélé que 80 % des environnements cloud utilisaient PostgreSQL et 45 % étaient directement exposés à Internet.
Une analyse JSON inadéquate a autorisé RCE sur le serveur MariaDB
Dans MariaDB, un bug de dépassement de tampon, suivi comme CVE-2026-32710, a été trouvé dans la fonction JSON_SCHEMA_VALID() à l’aide du code Xint. Cette vulnérabilité permet à un utilisateur authentifié de déclencher un crash qui, dans des conditions contrôlées, pourrait dégénérer en exécution de code à distance.
Par rapport aux failles de PostgreSQL, leur exploitation est ici moins simple. Une exécution réussie du code nécessiterait une manipulation de la disposition de la mémoire, réalisable uniquement dans des « environnements de laboratoire ». « Tout utilisateur pouvant ouvrir une session SQL – que ce soit via des informations d’identification volées, une injection SQL ou un mouvement latéral – peut atteindre ce chemin de code avec un seul appel de fonction », a déclaré l’équipe Xint Code dans un article de blog séparé.
Les versions 11.4.1-11.4.9 et 11.8.1-11.8.5 de MariaDB sont concernées, avec un correctif déployé dans 11.4.10 et 11.8.6, respectivement. La faille a été évaluée à 8,5 par GitHub, tandis que le NIST l’a classée à 9,9 sur 10 CVSS de base.
