PostgreSQL corrige 28 CVE d’un seul coup et rappelle la fin de vie de la version 14
Le 13 août 2026, le projet PostgreSQL a publié 18.6, 17.11, 16.15, 15.19, 14.24 et 19 Beta 3, corrigeant 28 failles de sécurité — un record — dont une douzaine de failles mémoire exploitables pour exécuter du code. Appliquez la mineure sans délai, et si vous êtes encore en version 14, planifiez la migration majeure avant le 12 novembre 2026.
13 août 2026. Le projet PostgreSQL publie six versions d’un coup : 18.6, 17.11, 16.15, 15.19, 14.24 et 19 Beta 3. Au menu, 28 failles de sécurité et plus de 110 bugs. Le 12 novembre 2026, la version 14 cessera de recevoir des correctifs.
C’est un lot de mise à jour qui ne ressemble à aucun autre. Vingt-huit CVE dans une seule salve de versions mineures, c’est le record absolu de l’histoire du projet — le précédent était de onze, posé trois mois plus tôt, en mai 2026. Pour un DBA ou un SRE qui fait tourner PostgreSQL en production, ce chiffre n’est pas une anecdote : il dit quelque chose sur la maturité de la surface d’attaque et sur l’urgence de bouger.
Un record de 28 CVE, dont une douzaine de failles mémoire exploitables
Le détail le plus important n’est pas le nombre, mais la nature des failles. Sur les 28 CVE, une bonne moitié est classée CVSS 8,8 avec le même motif : « exécute du code arbitraire », atteignable par un simple rôle authentifié, sans privilège d’administrateur (PR:L dans le vecteur CVSS). En clair : n’importe quel utilisateur disposant d’un compte applicatif peut, sur une instance vulnérable, faire exécuter du code au serveur.
La mécanique est presque toujours la même, et elle est de la mémoire non sûre. CVE-2026-14664 (débordement de tampon dans le moteur d’expressions rationnelles), CVE-2026-14669 (to_char), CVE-2026-14676 (pg_stat_statements), CVE-2026-14670 (objets liés plperl), CVE-2026-14671 (confusion de type dans le cache de plans refint), CVE-2026-16238, CVE-2026-16239, CVE-2026-19385 (pg_dump) : toutes décrivent un débordement de tampon ou une confusion de type qui transforme un rôle limité en exécution de code. La leçon structurelle est sans appel : PostgreSQL, écrit en C, continue de payer le coût de la mémoire non sûre, et une seule de ces failles suffit à escalader un compte applicatif en compromission complète.
Il y a aussi des pièges plus subtils, moins visibles qu’un débordement. CVE-2026-14663 fait que pgcrypto chiffre silencieusement en clair lorsqu’on lui demande un algorithme désactivé dans OpenSSL : le chiffrement semble réussir, mais le résultat est lisible. CVE-2026-14672 expose un oracle d’existence d’utilisateur via scram_iterations. CVE-2026-6464 fait qu’un échec précoce de COPY FROM STDIN dans psql traite les lignes de données restantes comme des commandes psql. Aucune de ces trois ne nécessite de privilège : elles touchent le client ou le protocole, pas seulement le serveur.
Ce rythme n’est pas un accident. Selon le décompte de HeroDevs, le projet a déjà publié 44 CVE depuis le début de l’année 2026 — plus que sur l’ensemble de l’année précédente. La pression vient de deux côtés : des audits plus systématiques (fuzzing, relecture assistée) qui remontent davantage de failles mémoire, et une surface d’attaque qui grandit à chaque extension et à chaque fonctionnalité. Pour l’équipe qui opère la base, la traduction est simple : le rythme des correctifs de sécurité cesse d’être un événement trimestriel, il devient continu.
La version 14 change la donne : une mineure, puis plus rien
Le second message de cette salve tient en une date. PostgreSQL 14 cessera de recevoir des correctifs le 12 novembre 2026. C’est la dernière version mineure de la branche 14 qui vient de sortir (14.24), et il n’y en aura plus qu’une seule autre avant l’arrêt — la politique de versionnement du projet prévoit une sortie trimestrielle, et la 14 approche de sa fin de support de cinq ans, atteinte en novembre.
Pour qui ? PostgreSQL 14 est encore massivement déployé : sortie en septembre 2021, elle a porté une grande partie des migrations des années 2022-2024. Si votre parc contient des instances en 14, vous n’êtes pas seul — mais vous êtes désormais sur un calendrier. La prochaine salve de correctifs trimestrielle, en novembre 2026, sera la dernière à couvrir la 14. Après, une CVE critique publiée sur la 14 restera non corrigée.
C’est précisément le genre de fenêtre que les attaquants surveillent. Une base PostgreSQL en fin de vie concentre deux risques : des failles connues non corrigées à partir de novembre, et une absence de chemin de mise à jour simple — la migration majeure (14 → 15, 16, 17 ou 18) ne se fait pas en un apt upgrade, elle se planifie.
Les trois étapes post-mise à jour à ne pas rater
L’annonce officielle signale trois points qui peuvent exiger une action manuelle après l’application de la mineure. Ils sont faciles à rater si on ne lit que le titre, et deux d’entre eux concernent des extensions très répandues.
Les builds d’index GIN en parallèle, l’extension btree_gist et l’extension ltree ont chacun un comportement modifié par cette salve. La conséquence pratique : si vous utilisez btree_gist ou ltree, prévoyez de vérifier leur comportement après la mise à jour — ces extensions stockent des données dans un format interne qui peut nécessiter une revalidation, pas seulement un redémarrage. C’est le genre de détail qui casse une réplication ou un index en silence si on l’ignore.
Un correctif mérite aussi une attention particulière pour les architectures haute disponibilité : la salve corrige un auto-blocage qui pouvait survenir pendant le rejeu du WAL généré par une version mineure plus ancienne, sur les versions 14, 15 et 16. Concrètement, un standby qui suit un primaire resté sur une mineure plus ancienne pouvait se figer. Si vous mettez à jour en plusieurs temps (primaire puis standby, ou l’inverse), vérifiez l’état de la réplication après chaque étape.
# 1. Figer la version exacte avant la mise à jour
psql -U postgres -d postgres -c "SELECT version();"
# 2. Dump de contrôle avant toute montée de version mineure
pg_dump -U postgres -Fc -f "pre-upgrade-$(date +%F).dump" postgres
# 3. Après la mise à jour, vérifier la réplication et les extensions sensibles
psql -U postgres -d postgres -c "SELECT * FROM pg_stat_replication;"
psql -U postgres -d postgres -c "SELECT extname, extversion FROM pg_extension WHERE extname IN ('btree_gist','ltree');"La règle de prudence est simple : une mineure PostgreSQL ne se déploie jamais « à chaud » sans un dump de contrôle et une vérification de la réplication. Ici, elle s’impose doublement à cause des trois points de l’annonce.
Le piège est aussi côté client : psql et pg_dump
Deux CVE de cette salve rappellent une vérité que beaucoup d’équipes oublient : le client fait partie du périmètre. CVE-2026-18408 (psql \unrestrict) permet à un serveur pg_dump malveillant de faire exécuter du code arbitraire dans le client psql de celui qui restaure. CVE-2026-19385 touche pg_dump lui-même avec un débordement de tampon.
Traduction opérationnelle : ne lancez jamais pg_dump ou psql contre un serveur auquel vous ne faites pas confiance, y compris un serveur de sauvegarde ou un miroir que vous croyez sain. L’attaquant n’a pas besoin d’écrire dans votre base pour vous compromettre : il lui suffit que vous lisiez depuis un hôte qu’il contrôle. C’est un rappel utile pour les chaînes de sauvegarde et les migrations entre environnements.
Verdict
Si vos instances tournent en version 14, votre priorité n’est pas la mineure — c’est la migration majeure. Planifiez-la avant le 12 novembre 2026 : pg_upgrade pour les gros volumes, pg_dump/pg_restore pour les petits, et surtout un test sur une copie avant la bascule. La 14.24 est votre avant-dernière occasion de partir en restant couvert.
Si vous êtes déjà en 15, 16, 17 ou 18, appliquez la mineure correspondante ce week-end, pas au prochain cycle de maintenance. Le record de 28 CVE — dont une douzaine exploitables par un simple rôle authentifié — ne laisse aucune marge d’attente, et les trois points post-mise à jour demandent un déploiement attentif, pas un apt upgrade les yeux fermés.
Le signal de fond dépasse PostgreSQL : la mémoire non sûre reste le réservoir de failles le plus fiable de l’écosystème des bases de données. Chaque salve de correctifs comme celle-ci est un argument de plus pour surveiller les projets qui réécrivent ces couches en langage mémoire-sûr — et pour traiter vos bases comme ce qu’elles sont : des systèmes critiques avec un compte à rebours de support, pas des briques qu’on oublie.