Un utilisateur de base de données capable de créer des objets peut, avec la faille CVE-2026-6460, faire exécuter du code au serveur PostgreSQL. Les correctifs sont sortis le 12 novembre dans les versions 18.7, 17.12, 16.16, 15.20 et 14.25, mais mettre à jour le serveur ne suffit pas : les extensions écrites en C doivent aussi être recompilées.

Ce qui est touché

Le défaut est une confusion de type, notée 8,8 sur 10 en CVSS. Il touche toutes les versions antérieures aux cinq publiées le 12 novembre, selon l’avis du projet PostgreSQL. Le code s’exécute avec les droits de l’utilisateur du système d’exploitation qui fait tourner la base, d’après The Hacker News.

Le mécanisme tient aux types composites, ces types bâtis à partir de champs nommés, chacun avec son propre type. Quand on modifie le type d’un champ (par un ALTER ... SET DATA TYPE, principalement), d’anciennes valeurs peuvent subsister ailleurs dans le serveur. Celui-ci les lit alors comme si elles avaient le nouveau type.

Les correctifs ajoutent un système de versions qui permet au serveur de repérer une valeur qui ne correspond plus à son descripteur. C’est ce mécanisme qui oblige à recompiler les extensions C : le projet précise que la protection complète l’exige, et que certaines extensions demanderont des modifications du code source.

Quant à l’âge de la faille, le chercheur Mehmet Ince la fait remonter au 5 mai 2004, date à laquelle PostgreSQL a permis de changer le type d’une colonne. Son exploit s’appuie en plus sur une modification du 14 mai 2015.

Une gravité réelle, mais sous conditions

Aucune attaque n’a été signalée. Le PostgreSQL Global Development Group n’en mentionne pas, et l’évaluation de la CISA dans la fiche CVE classe l’exploitation comme « aucune ». Ce n’est pas pour autant théorique : Mehmet Ince a publié cette semaine une analyse technique décrivant un exploit fonctionnel sur PostgreSQL 18.6. Elle donne le SQL qui fait planter un serveur non corrigé, puis une seconde étape qui fait fuiter des adresses mémoire. La dernière étape, celle qui lance une commande, n’y figure pas.

Le vecteur CVSS indique une attaque par le réseau, de faible complexité, sans interaction d’un utilisateur, mais avec un compte aux privilèges faibles. Reste la question des privilèges. Selon The Hacker News, Ince affirme avoir pu « déclencher ce plantage avec un rôle de connexion au plus bas niveau de privilèges ». L’avis du projet parle seulement d’un créateur d’objets, et Red Hat estime dans son évaluation que l’attaquant doit disposer d’une connexion avec le droit de créer ou de modifier des objets. Aucune de ces sources ne dit si un compte aux droits par défaut peut aller au-delà du plantage jusqu’à l’exécution de code.

Le même chercheur a adapté son exploit aux services PostgreSQL managés et partagé des preuves de concept avec leurs équipes de sécurité en août : AWS (Aurora et RDS), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks et Ubicloud. Son analyse n’indique pas où en est chaque service.

Cette faille n’est qu’une des 52 corrigées. Le projet en note 32 à 8,8, le score le plus élevé de la livraison. D’après les scores de son index des vulnérabilités, relève The Hacker News, une seule, côté serveur, n’exige ni connexion ni action d’un utilisateur : CVE-2026-116322, qui permet à un client non authentifié de provoquer le redémarrage d’un serveur PostgreSQL 18 (CVSS 5,3). Côté outils clients, une archive piégée peut faire exécuter du code à pg_restore, et un serveur source compromis peut en faire autant avec psql via le script de restauration issu d’une sortie tar de pg_dump.

Que faire maintenant

• Passer le serveur à 18.7, 17.12, 16.16, 15.20 ou 14.25, selon la version majeure.
• Recompiler ou mettre à jour toutes les extensions C en même temps. Les extensions construites pour d’anciennes versions se chargent encore, mais rien ne garantit qu’elles soient protégées contre les failles corrigées, préviennent les mainteneurs des paquets RPM du projet. Certaines exigeront aussi des modifications du code source, et une extension recompilée peut refuser de se charger sur un serveur pas encore mis à jour.
• Redémarrer PostgreSQL juste après la mise à jour s’il tourne hors de l’unité de service de son paquet, par exemple sous Patroni, conseille l’un des mainteneurs RPM dans un billet.
• Mettre à jour pg_dump, pg_restore, reindexdb et vacuumdb sur chaque machine qui les utilise.
• Ne pas désactiver les nouveaux contrôles avec le paramètre composite_type_mismatch : le projet avertit que cela comporte des risques de sécurité.
• Réindexer les index concernés, comme le détaille l’annonce de version, car plusieurs bogues peuvent corrompre des index. Les sauvegardes incrémentales existantes ne sont plus fiables : le projet recommande d’en faire une nouvelle complète après la mise à jour et de repartir de celle-ci.

Aucun contournement n’est proposé pour les serveurs qui ne peuvent pas être mis à jour tout de suite. PostgreSQL 14 est en fin de vie et la 14.25 est sa dernière version. Les branches plus anciennes sont aussi concernées, mais n’ont reçu aucun correctif : pour être protégé, il faut migrer vers une branche maintenue. Reste à voir ce que diront les fournisseurs de services managés, et si le détail de la dernière étape de l’exploit finit par être publié.

Fiche technique

Données : NVD (NIST) et GitHub Advisory Database (CC BY 4.0, données adaptées).

Sources

• E.1. Release 18.7, postgresql.org
• CVE-2026-6460, postgresql.org
• PostgreSQL Patches 52 Flaws, Including 22-Year-Old Bug Enabling Authenticated RCE, The Hacker News, 13 novembre 2026
• PostgreSQL, falla nascosta da 22 anni permette di eseguire codice, Il Software, 13 novembre 2026
• GHSA-j4qg-6655-x9r7 : Improper locking in PostgreSQL startup processing allows an unauthenticated network…, GitHub Advisory Database (CC BY 4.0)
• CVE-2026-116322, NVD (NIST)
• GHSA-7m3p-q8w8-4qgh : Type confusion in PostgreSQL allows an object creator to execute arbitrary code as the…, GitHub Advisory Database (CC BY 4.0)
• CVE-2026-6460, NVD (NIST)