PostgreSQL CVE-2026-6460 : les utilisateurs de base de données pouvant créer des objets peuvent exécuter du code sur le serveur

Ce qui s'est passé

Le 12 novembre 2026, le PostgreSQL Global Development Group a publié PostgreSQL 18.7, 17.12, 16.16, 15.20 et 14.25. Selon The Hacker News, ces versions corrigent 52 failles de sécurité. La plus grave est CVE-2026-6460 (CVSS 8.8), une faille de confusion de type dans le cœur du serveur.

Un utilisateur de base de données pouvant créer des objets peut utiliser ALTER ... SET DATA TYPE pour amener le serveur à lire une valeur obsolète comme si elle possédait un nouveau type. D'autres instructions DDL peuvent faire de même, par exemple ALTER TABLE ... ADD COLUMN; ROLLBACK; ALTER TABLE ... ADD COLUMN. Cela permet à l'utilisateur d'exécuter du code arbitraire avec le compte système qui fait fonctionner PostgreSQL. Le correctif ajoute des vérifications de version afin que le serveur puisse détecter les valeurs qui ne correspondent plus à leur type.

Le chercheur en sécurité Mehmet Ince a publié une analyse technique accompagnée d'un exploit fonctionnel, qu'il a démontré sur PostgreSQL 18.6. Cette analyse contient le code SQL qui fait planter un serveur non corrigé ainsi qu'une étape qui divulgue des adresses mémoire. Elle ne contient pas l'étape finale qui exécute une commande. Il a indiqué qu'il pouvait provoquer le plantage avec un rôle de connexion disposant des privilèges les plus faibles. Les sources ne précisent pas si un compte ne disposant que des privilèges par défaut peut aller plus loin et exécuter du code. Red Hat indique qu'un attaquant a besoin d'une connexion à la base de données capable de créer ou de modifier des objets.

Le projet PostgreSQL n'a signalé aucune attaque exploitant cette faille, et la CISA ne la répertorie pas comme exploitée.

Les mêmes versions corrigent d'autres failles, dont CVE-2026-116322, qui permet à un client non authentifié de forcer le redémarrage des serveurs PostgreSQL 18. Elles corrigent également des failles dans les outils clients : une archive malveillante peut faire exécuter du code par pg_restore à l'utilisateur qui le lance, et un serveur source compromis peut faire exécuter du code à psql via le script de restauration de la sortie tar de pg_dump.

Qui est concerné

• PostgreSQL 18 avant 18.7, 17 avant 17.12, 16 avant 16.16, 15 avant 15.20 et 14 avant 14.25.
• Les versions majeures plus anciennes sont également concernées et ne recevront pas de mise à jour. PostgreSQL 14 est désormais en fin de vie, et 14.25 est sa dernière version.
• Le risque est maximal sur les serveurs où des personnes que vous ne connaissez pas entièrement disposent d'une connexion à la base de données pouvant créer ou modifier des objets. Cela concerne notamment l'hébergement mutualisé, les bases de données confiées à des clients et les applications web dont le compte de base de données possède son schéma. Si un attaquant prend le contrôle d'une telle application, par exemple par injection SQL, il pourrait utiliser son compte de base de données de cette manière.
• Services managés : le chercheur a partagé des preuves de concept avec AWS (RDS, Aurora), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks et Ubicloud. L'état actuel de leurs correctifs n'est pas connu. Consultez les avis de votre fournisseur.
• Les serveurs qui n'exécutent pas PostgreSQL ne sont pas concernés. MySQL et MariaDB ne sont pas concernés.

Que faire maintenant

1. Sauvegardez la configuration de PostgreSQL (par exemple postgresql.conf et pg_hba.conf) et assurez-vous de disposer d'une sauvegarde récente de la base de données.
2. Mettez à jour le serveur vers la version corrigée de votre version majeure : 18.7, 17.12, 16.16, 15.20 ou 14.25. Si vous utilisez les paquets de votre distribution (Debian, Ubuntu, RHEL et dérivées), installez les paquets corrigés listés dans l'avis de votre distribution dès qu'ils sont disponibles. Utilisez ensuite le gestionnaire de paquets comme d'habitude (apt update && apt upgrade ou dnf upgrade).
3. Mettez à jour ou recompilez toutes les extensions en langage C en même temps que le serveur. Les mainteneurs RPM du projet avertissent que les extensions compilées avec les anciennes versions se chargent encore, mais risquent de ne pas être protégées. Certaines extensions nécessitent également des modifications du code source. Les paquets d'extensions des dépôts RPM de PostgreSQL exigent désormais la nouvelle version mineure.
4. Redémarrez PostgreSQL. S'il fonctionne en dehors de l'unité de service propre à son paquet, par exemple sous Patroni, redémarrez-le manuellement immédiatement après la mise à jour.
5. Suivez les étapes de réindexation indiquées dans l'annonce officielle de la version. Si vous utilisez des sauvegardes incrémentielles, effectuez une nouvelle sauvegarde complète et basez les sauvegardes incrémentielles futures sur celle-ci.
6. Mettez à jour les outils clients tels que pg_dump, pg_restore, psql, reindexdb et vacuumdb sur chaque machine qui les utilise, y compris les serveurs de sauvegarde et les postes d'administration.
7. N'utilisez pas le nouveau paramètre composite_type_mismatch pour désactiver les nouvelles vérifications. Le projet indique que cela comporte des risques pour la sécurité.
8. Si vous ne pouvez pas mettre à jour immédiatement, gardez à l'esprit que le projet ne propose aucune solution de contournement. En attendant la mise à jour, examinez quels comptes peuvent créer ou modifier des objets, en particulier les comptes utilisés par les applications web ou confiés à des clients, et assurez-vous que PostgreSQL n'est pas accessible depuis Internet, sauf si cela est nécessaire.
9. Si vous exécutez encore PostgreSQL 14 ou une version plus ancienne, prévoyez une migration vers une version majeure prise en charge.

Comment vérifier si vous êtes concerné

• Vérifiez la version du serveur en cours d'exécution avec psql -c 'SELECT version();' ou SHOW server_version;. Les versions inférieures à 18.7, 17.12, 16.16, 15.20 ou 14.25 dans leur série majeure sont concernées.
• Vérifiez les binaires et paquets installés avec postgres -V, dpkg -l | grep postgresql ou rpm -qa | grep postgresql. Redémarrez le serveur si la version en cours d'exécution est plus ancienne que la version installée.
• Listez les extensions installées avec SELECT extname, extversion FROM pg_extension; dans chaque base de données. Assurez-vous que chaque extension C a été mise à jour ou recompilée pour la nouvelle version.
• Vérifiez les journaux de PostgreSQL pour détecter des plantages inattendus de processus serveur, comme des processus terminés par un signal. L'exploit publié fait planter les serveurs non corrigés, il est donc utile d'examiner de près ce type de plantage.

Sources

• https://nvd.nist.gov/vuln/detail/CVE-2026-6460
• https://www.postgresql.org/support/security/CVE-2026-6460/