PostgreSQL : 52 failles, dont un RCE vieux de 22 ans

Ce qui se passe

Le 12 novembre, le projet PostgreSQL a livré cinq versions correctives : 18.7, 17.12, 16.16, 15.20 et 14.25. Elles réparent 52 failles, dont 32 notées 8,8, le score le plus haut de la livraison. La plus lourde, CVE-2026-6460 (CVSS 8,8), est une confusion de types : un utilisateur de la base qui peut créer des objets fait exécuter du code au serveur, avec les droits du compte système qui lance PostgreSQL. Ni le projet ni la fiche CVE ne signalent d'attaque.

Le mécanisme

La faille touche les types composites, faits de champs nommés ayant chacun leur type. On peut changer le type d'un champ alors que d'anciennes valeurs de ce type circulent encore dans le serveur, qui relit alors une ancienne valeur comme si elle avait le nouveau type. Le correctif ajoute des contrôles de version pour repérer une valeur qui ne correspond plus à son type.

Le chercheur Mehmet Ince a publié une analyse avec un exploit fonctionnel sur PostgreSQL 18.6 : préparer une requête qui porte une valeur, changer le type d'un de ses champs, puis l'exécuter. Il fait remonter l'origine au 5 mai 2004, quand PostgreSQL a appris à changer le type d'une colonne ; sa technique d'exécution s'appuie sur un changement du 14 mai 2015. Son texte donne le SQL du plantage et d'une fuite d'adresses mémoire, pas celui de la dernière étape. Il avait transmis des preuves de concept en août à AWS (Aurora et RDS), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks et Ubicloud ; l'état de correction de chaque service n'est pas détaillé.

Une zone d'ombre

Quels privilèges faut-il vraiment ? L'avis du projet parle de quelqu'un qui peut créer des objets, Red Hat d'un compte qui peut en créer ou en modifier, et Ince dit avoir provoqué le plantage avec un rôle de connexion au plus bas niveau. Aucune de ces sources ne dit si un compte aux droits par défaut peut aller du plantage à l'exécution de code. En attendant, traitez tout compte qui crée des objets comme dangereux.

Les autres correctifs notables

CVE-2026-116322 : un client sans authentification peut faire redémarrer un serveur PostgreSQL 18. D'après les scores du projet, c'est la seule faille du serveur qui n'exige ni compte ni action d'un utilisateur.
pg_restore peut exécuter du code à partir d'une archive forgée, sous l'utilisateur qui la restaure.
psql peut exécuter du code par le script de restauration d'une sortie pg_dump au format tar, si le serveur source est compromis.

Comment s'y prendre

Passer chaque serveur à la version de sa branche : 18.7, 17.12, 16.16, 15.20 ou 14.25.
Recompiler ou mettre à jour toutes les extensions en C en même temps. Compilées contre une version plus ancienne, elles se chargent encore mais peuvent ne pas être protégées ; certaines demanderont des changements de code source. Les paquets d'extensions des dépôts RPM du projet exigent désormais la nouvelle version mineure, et une extension recompilée peut refuser de se charger sur un ancien serveur.
Si PostgreSQL tourne hors du service du paquet, par exemple sous Patroni, le redémarrer juste après la mise à jour.
Mettre à jour pg_dump, pg_restore, reindexdb et vacuumdb sur chaque machine qui les lance.
Ne pas utiliser le nouveau paramètre composite_type_mismatch pour couper les contrôles : le projet y voit un risque de sécurité.
Suivre ensuite les étapes de réindexation de l'annonce de version. Avec des sauvegardes incrémentales, faire une nouvelle sauvegarde complète et y rattacher les suivantes.

Ni l'avis ni les notes de version ne proposent de contournement pour un serveur qu'on ne peut pas mettre à jour. PostgreSQL 14 est en fin de vie : 14.25 est sa dernière version, et les branches plus anciennes, elles aussi touchées, n'ont rien reçu.

Source : The Hacker News, en anglais, qui renvoie à l'avis du projet et à l'analyse de Mehmet Ince.