PostgreSQL corrige un bogue vieux de 22 ans qui permet d'exécuter du code sur le serveur

Le projet PostgreSQL a publié le 12 novembre les mises à jour 18.7, 17.12, 16.16, 15.20 et 14.25. Selon le projet, elles corrigent 52 vulnérabilités et plus de 140 autres bogues. La plus commentée est CVE-2026-6460, notée 8,8 sur 10 : un utilisateur de la base autorisé à créer des objets peut exécuter son propre code sur le serveur avec les droits de l'utilisateur système qui fait tourner PostgreSQL. Le projet a attribué la même note à 31 autres failles de cette version. Aucune attaque exploitant CVE-2026-6460 n'a été signalée.

Pourquoi le bogue a 22 ans

La faille concerne les types composites, c'est-à-dire des types formés de plusieurs champs nommés. On peut changer le type d'un champ alors que d'anciennes valeurs restent stockées ailleurs dans le serveur, qui lit alors une ancienne valeur comme si elle avait déjà le nouveau type. Dans son avis de sécurité, le projet reconnaît que le système suivait mal le type des valeurs. Le chercheur Mehmet Ince, qui a présenté un exploit fonctionnel sur la version 18.6, fait remonter le problème au 5 mai 2004, quand PostgreSQL a permis de changer le type d'une colonne, rapporte The Hacker News.

Selon Ince, il a pu faire planter un serveur non corrigé avec le rôle le moins privilégié. Aucune des sources ne précise si un tel compte peut aller jusqu'à exécuter du code. En août, il a adapté l'exploit aux bases de données gérées et l'a transmis aux équipes de sécurité d'AWS, Microsoft Azure, Google, Supabase, Databricks et Ubicloud. On ne sait pas si toutes ont déjà corrigé.

Qui est concerné

Surtout ceux qui laissent d'autres personnes accéder à la même base : hébergeurs, services cloud et tout projet qui donne à ses clients leur propre compte PostgreSQL. Si seule votre application parle à votre base, un attaquant extérieur devrait d'abord y obtenir des droits. Les outils clients ont aussi été corrigés : une archive piégée peut pousser pg_restore à exécuter du code sur la machine de celui qui restaure la base. Une seule des 52 failles fonctionne sans connexion, et elle permet de redémarrer un serveur PostgreSQL 18.

Ce n'est pas la seule mise à jour serveur de la semaine à installer sans tarder : nous avons récemment parlé d'une faille HTTP/2 dans Apache.

Que faire

• Mettez le serveur à jour en 18.7, 17.12, 16.16, 15.20 ou 14.25 selon votre version majeure. Pas besoin de sauvegarder et recharger la base.
• Recompilez ou mettez à jour toutes les extensions en C en même temps. Les anciennes versions se chargent encore, mais selon les mainteneurs des paquets RPM elles risquent de ne pas être protégées.
• Mettez à jour pg_dump, pg_restore, reindexdb et vacuumdb sur toutes les machines qui les utilisent.
• Si PostgreSQL tourne hors de l'unité de service du paquet, par exemple sous Patroni, redémarrez-le juste après la mise à jour.
• Ne désactivez pas les nouvelles vérifications avec le paramètre composite_type_mismatch : le projet prévient que c'est risqué.
• Suivez les étapes de la section « Updating » de l'annonce : reconstruire les index concernés (GIN, GiST avec pg_trgm, B-tree sur des colonnes bpchar) et, si vous utilisez des sauvegardes incrémentales, faire une nouvelle sauvegarde complète.
• Si vous êtes en version 14 ou antérieure, prévoyez une migration : il n'y aura plus de correctifs après la 14.25.