En bref. Le PostgreSQL Global Development Group a publié le 12 novembre 2026 les versions 18.7, 17.12, 16.16, 15.20 et 14.25, qui corrigent 52 vulnérabilités et plus de 140 bugs. 32 de ces vulnérabilités sont notées 8.8 sur l'échelle CVSS (Common Vulnerability Scoring System), et 28 intitulés mentionnent une exécution de code arbitraire, avérée ou possible. PostgreSQL 14 est désormais en fin de vie : cette version 14.25 est sa dernière. Il faut mettre à jour, puis appliquer certaines étapes post-mise à jour (réindexation, nouvelle sauvegarde complète) selon votre usage.
Ce qui s'est passé
L'annonce officielle du projet PostgreSQL, datée du 12 novembre 2026, couvre toutes les versions supportées ainsi que la deuxième version candidate (RC 2) de PostgreSQL 19. Le CERT-FR a publié le 13 novembre l'avis CERTFR-2026-AVI-1530, qui résume : certaines de ces vulnérabilités permettent une exécution de code arbitraire à distance, un déni de service à distance et une atteinte à la confidentialité des données.
Deux autres informations de l'annonce :
- PostgreSQL 14 est en fin de vie. Elle ne recevra plus de correctifs de sécurité ni de corrections de bugs. Le projet recommande de planifier une migration vers une version supportée.
- PostgreSQL 19 devrait être disponible le 19 novembre 2026, sauf problème imposant un report ou une autre version candidate.
Ce que corrigent ces versions
Les vulnérabilités, par famille
L'annonce liste les 52 CVE avec leur score CVSS v3.1. Répartition des scores : 32 à 8.8, 2 à 8.1, 1 à 8, 3 à 7.2, 1 à 6.5, 3 à 5.4, 1 à 5.3, 7 à 4.3, 1 à 3.7 et 1 à 3.1.
Les familles qui ressortent des intitulés :
- Corruption mémoire et confusion de types dans le serveur. La majorité des failles à 8.8 : use-after-free (utilisation d'une zone mémoire déjà libérée), débordements de tampon, dépassements d'entiers et confusions de types, dans des opérations comme
ALTER ... SET DATA TYPE, les agrégats min/max,ts_rank_cd()outsvector_delete(). Leur intitulé indique une exécution de code arbitraire. - Langages procéduraux. Cinq failles concernent plperl et une pltcl, dont plusieurs use-after-free.
- Outils clients.
pg_restorepeut exécuter du code faute de valider les archives non textuelles (CVE-2026-116314),pg_dumpest concerné par une injection SQL via un nom de contrainte (CVE-2026-116318) et une injection de commandes psql dans le fichierrestore.sqld'une archive tar (CVE-2026-116330).reindexdb(CVE-2026-116325) etvacuumdb(CVE-2026-116313) sont aussi touchés. - Contournements de contrôles d'accès.
INSERT ... ON CONFLICTpeut lire des lignes malgré des politiques de sécurité au niveau des lignes (CVE-2026-120154), ou lire et modifier des lignes malgré la condition WHERE d'une vue modifiable automatiquement (CVE-2026-16237) ;DROP OWNEDpeut retirer des politiques restrictives de tables qui n'appartiennent pas à l'utilisateur (CVE-2026-116311) ;REASSIGN OWNEDcontourne certains contrôles de rôle (CVE-2026-120146). - Réplication logique. Elle peut écrire dans les catalogues système de l'abonné et ainsi exécuter du code arbitraire (CVE-2026-120145).
- Extensions et scripts. Gestion des schémas et substitutions dans les scripts d'extension permettant d'exécuter du SQL arbitraire (CVE-2026-6467, CVE-2026-120153) ;
dblinket les souscriptions peuvent ajouter du contenu à des fichiers arbitraires (CVE-2026-14661).
Une seule faille est explicitement antérieure à l'authentification dans son intitulé : une demande d'annulation peut provoquer une fuite de verrou (spinlock), notée 5.3 (CVE-2026-116322).
Lecture du risque
Les intitulés des failles les plus graves décrivent pour la plupart des opérations SQL, des fonctions ou des langages procéduraux. Notre lecture, qui n'est pas une information de l'annonce : un attaquant doit en général pouvoir exécuter des requêtes sur la base. Le risque est donc le plus élevé là où des utilisateurs peu fiables, une application compromise ou plusieurs clients partagent la même instance, et là où des fonctions en plperl ou pltcl sont activées. La page sécurité de PostgreSQL nuance ce « en général » : d'après leur vecteur CVSS, quelques failles n'exigent aucun compte sur la base visée, dont la réplication logique (CVE-2026-120145) et les failles de pg_restore et pg_dump (CVE-2026-116314, CVE-2026-116330), toutes trois à condition qu'une victime agisse.
Les failles des outils clients changent la donne pour un autre scénario : restaurer une sauvegarde reçue d'un tiers ou d'une source non maîtrisée, ou exécuter pg_dump sur une base contrôlée par quelqu'un d'autre.
Les bugs de corruption de données
Parmi les plus de 140 bugs corrigés, l'annonce cite des problèmes qui peuvent corrompre des index ou des sauvegardes : index GIN, index GiST de pg_trgm, index B-tree sur des colonnes bpchar sans longueur (résultats faux sur les parcours d'index seul), REINDEX CONCURRENTLY sur une table TOAST, sauvegardes incrémentales, et l'export ou l'import d'instantanés pris sur un serveur secondaire, qui peut corrompre à la fois la sortie de pg_dump et les données du secondaire. L'annonce cite aussi une perte possible de lignes lors d'une réécriture de table (CLUSTER, VACUUM FULL) et des cas de perte ou d'incohérence de données après un crash.
Qui est concerné
- Toute instance PostgreSQL en versions 18, 17, 16, 15 ou 14 non mise à jour. Le tableau de la page sécurité de PostgreSQL précise, pour chaque CVE, les versions corrigées : certaines failles ne touchent que les versions les plus récentes.
- En priorité : les bases partagées entre plusieurs applications ou clients, les bases où des utilisateurs peuvent créer des fonctions, les instances qui utilisent plperl, pltcl,
dblinkou la réplication logique, et les processus de restauration de sauvegardes. - Les équipes encore en PostgreSQL 14, qui n'auront plus de correctif pour les prochaines failles.
- Les services gérés dans le cloud dépendent du calendrier de leur fournisseur : vérifiez sa console ou ses annonces.
Mettre à jour : contrôles concrets
1. Installer la version mineure
Selon l'annonce, ces mises à jour sont cumulatives et ne demandent ni export-réimport ni pg_upgrade : il suffit d'arrêter PostgreSQL et de mettre à jour les binaires. À titre de bonne pratique, pensez aux paquets clients (pg_dump, pg_restore, psql, reindexdb, vacuumdb) sur les postes et serveurs de sauvegarde, pas seulement au serveur.
2. Appliquer les étapes post-mise à jour
L'annonce liste les cas qui demandent une action :
- GIN : réindexer si vous soupçonnez un index touché.
- pg_trgm : réindexer les index GiST qui utilisent la classe d'opérateurs
gist_trgm_ops. - Erreurs « missing chunk number » : réindexer la table concernée, ce qui réindexe aussi sa table TOAST.
- Sauvegardes incrémentales : faire une nouvelle sauvegarde complète et repartir d'elle pour les incrémentales suivantes.
- Tables partitionnées : rechercher les contraintes
NOT NULL NO INHERITsur les tables partitionnées (l'annonce fournit la requête) et les supprimer ou les réparer avecALTER TABLE ... ALTER CONSTRAINT ... INHERIT, qui échoue si une partition contient des valeurs NULL dans la colonne. - Index B-tree sur
bpcharsans longueur : les réindexer. Les colonneschar(n)ne sont pas concernées.
Si vous avez sauté des versions mineures, l'annonce rappelle de vérifier aussi les étapes des versions précédentes.
3. Réduire l'exposition en attendant
Ces mesures sont des bonnes pratiques, pas des consignes de l'annonce :
- retirer les droits de création de fonctions et le droit
CREATEsur les schémas aux rôles applicatifs qui n'en ont pas besoin ; - désactiver les langages et extensions non utilisés (plperl, pltcl,
dblink) ; - ne restaurer que des sauvegardes de provenance connue, avec des binaires à jour ;
- limiter l'accès réseau au port de la base aux seuls serveurs applicatifs.
4. Planifier la sortie de PostgreSQL 14
Une version en fin de vie accumule les failles connues sans correctif. Inventoriez vos instances en 14, choisissez la version cible et testez la migration avec pg_upgrade ou pg_dump/pg_restore. Pour PostgreSQL 19, l'annonce signale qu'une réindexation peut être nécessaire après pg_upgrade pour les index utilisant la recherche plein texte, pg_trgm ou fuzzystrmatch.
Méthode de vérification
SELECT version();sur chaque instance, et comparaison avec la liste des versions corrigées.- La version des binaires clients sur les serveurs de sauvegarde (
pg_dump --version). - Un inventaire automatique des instances, y compris les conteneurs et les environnements de développement : une image Docker figée sur une ancienne version mineure est une instance comme une autre.
- Dans votre analyse de dépendances, une alerte sur toute image de base PostgreSQL antérieure aux versions du 12 novembre 2026.
FAQ
Quelles versions de PostgreSQL corrigent les CVE de novembre 2026 ?
Les versions 18.7, 17.12, 16.16, 15.20 et 14.25, publiées le 12 novembre 2026, ainsi que PostgreSQL 19 RC 2.
Combien de vulnérabilités sont corrigées ?
52 vulnérabilités, dont 32 notées 8.8 en CVSS v3.1, et plus de 140 bugs.
PostgreSQL 14 est-il encore supporté ?
Non. La version 14.25 est la dernière : PostgreSQL 14 ne recevra plus de correctifs de sécurité ni de corrections de bugs.
Faut-il un pg_upgrade pour appliquer la mise à jour ?
Non pour une version mineure : arrêter PostgreSQL et remplacer les binaires suffit, puis appliquer les étapes post-mise à jour qui concernent votre usage (réindexation, nouvelle sauvegarde complète).
Sources
- PostgreSQL Global Development Group, PostgreSQL 18.7, 17.12, 16.16, 15.20, 14.25, and 19 RC 2 Released!, 12 novembre 2026 : https://www.postgresql.org/about/news/postgresql-187-1712-1616-1520-1425-and-19-rc-2-released-3442/
- PostgreSQL, page des vulnérabilités de sécurité : https://www.postgresql.org/support/security/
- CERT-FR, avis CERTFR-2026-AVI-1530, Multiples vulnérabilités dans PostgreSQL, 13 novembre 2026 : https://www.cert.cyber.gouv.fr/avis/CERTFR-2026-AVI-1530
Pour intégrer la veille et le suivi des versions de vos bases et images dans votre pipeline, WeeSec accompagne les équipes en DevSecOps.