Ce que font ces deux vulnérabilités
CVE-2026-6471 (CVSS 7.2) touche le mécanisme de décodage logique introduit en PostgreSQL 9.4. Un compte portant l'attribut REPLICATION peut spécifier un plugin de sortie arbitraire lors de la création d'un slot de réplication logique. Avant le correctif, PostgreSQL chargeait le fichier demandé via dlopen sans vérifier sa provenance, ce qui permettait d'exécuter du code avec les droits du compte système postgres. L'attaquant n'a pas besoin d'un accès réseau direct à votre instance : un pair de réplication compromis, un outil CDC (Change Data Capture) ou un utilisateur interne disposant de l'attribut REPLICATION suffisent. Le correctif ajoute un paramètre output_plugin_libraries qui liste les bibliothèques autorisées — par défaut pgoutput et test_decoding uniquement.
CVE-2026-14669 (CVSS 8.8) est un débordement de tampon de tas dans la fonction to_char(timestamptz). La fonction construit un tampon de travail depuis la chaîne de format, mais les chemins de traitement des fuseaux horaires POSIX copient l'abréviation fournie par l'utilisateur dans ce tampon sans vérification de longueur. Un utilisateur authentifié ordinaire peut déclencher la vulnérabilité en passant une abréviation de fuseau horaire excessivement longue, ce qui écrase les structures adjacentes du tas et détourne le flux d'exécution pour atteindre l'exécution de code arbitraire avec les droits du compte postgres.
Comparatif des deux CVE
| Critère | CVE-2026-6471 | CVE-2026-14669 |
|---|---|---|
| Score CVSS | 7.2 (High) | 8.8 (High) |
| Composant | Décodage logique | `to_char(timestamptz)` |
| Vecteur | Réseau | Réseau |
| Privilège minimal requis | Attribut REPLICATION | Utilisateur authentifié |
| Accès public requis | Non | Non |
| Type d'impact | Exécution de code arbitraire | Exécution de code arbitraire |
| Date de correction | 2026-08-13 | 2026-08-13 |
Versions affectées et versions corrigées
Les deux CVE touchent toutes les branches maintenues de PostgreSQL. Les versions corrigées, publiées simultanément le 13 août 2026, sont : PostgreSQL 18.6, 17.11, 16.15, 15.19 et 14.24. Toute instance qui tourne sur une version antérieure à ces numéros est exposée. PostgreSQL 13 et les versions antérieures ont atteint leur fin de vie et ne reçoivent plus de correctifs : si votre instance tourne sur une branche en fin de vie, ces CVE s'ajoutent à un risque structurel déjà existant. Les applications qui embarquent PostgreSQL — Supabase, NocoDB, Gitea, Twenty CRM, Planka — sont affectées si elles n'ont pas encore mis à jour leur image de base.
Avant de patcher : auditer vos rôles de réplication
Avant d'appliquer le correctif, il vaut la peine de savoir combien de comptes portent l'attribut REPLICATION sur vos instances. La requête suivante liste tous les rôles concernés :
SELECT rolname, rolreplication, rolsuper FROM pg_roles WHERE rolreplication = true OR rolsuper = true ORDER BY rolsuper DESC, rolname;
Si vous trouvez des comptes avec REPLICATION qui ne servent pas à une réplication effective (backup, CDC, monitoring), révoquez l'attribut : ALTER ROLE nom_du_role NOREPLICATION;. C'est une mesure de contournement partielle en attendant le patch, et une bonne pratique permanente.
Patcher via apt sur Debian et Ubuntu
Vérifier la version actuelle
Connectez-vous à votre instance et relevez la version en cours : psql -U postgres -c 'SELECT version();'. Notez la branche (14, 15, 16, 17 ou 18) pour installer le bon paquet cible.
S'assurer que le dépôt PGDG est configuré
Les dépôts Debian et Ubuntu standard livrent souvent des versions en retard. Pour obtenir les correctifs à jour, utilisez le dépôt officiel PostgreSQL. Si ce n'est pas déjà fait : sudo apt install -y postgresql-common && sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh. Ce script configure le dépôt PGDG pour votre distribution.
Mettre à jour les paquets
Une mise à jour mineure (17.10 → 17.11, 16.14 → 16.15, etc.) ne requiert pas pg_upgradecluster et conserve vos données en place. Exécutez : sudo apt update && sudo apt install postgresql-17 (adaptez 17 à votre branche). APT installera la version corrigée. Pour les autres branches : sudo apt install postgresql-16, postgresql-15, postgresql-14 selon votre cas.
Redémarrer le service
Le service doit être redémarré pour charger le nouveau binaire : sudo systemctl restart postgresql. Vérifiez ensuite que le service est reparti correctement : sudo systemctl status postgresql.
Confirmer la version après le patch
Reconnectez-vous et vérifiez que la version affichée correspond au correctif : psql -U postgres -c 'SELECT version();'. Vous devez voir 17.11, 16.15, 15.19, 14.24 ou 18.6 selon votre branche.
Patcher via Docker
Tirer l'image corrigée
Les images officielles postgres sur Docker Hub ont été mises à jour avec les versions corrigées. Tirez l'image correspondant à votre branche : docker pull postgres:17.11, ou avec le tag mineur de votre branche (postgres:16.15, postgres:15.19, postgres:14.24). Pour les images Alpine : docker pull postgres:17.11-alpine.
Relancer le conteneur
Si vous utilisez Docker Compose, mettez à jour le tag d'image dans votre docker-compose.yml, puis : docker compose pull && docker compose up -d. Pour un conteneur lancé directement : docker stop postgres-container && docker rm postgres-container, puis relancez avec la nouvelle image. Vos données restent dans le volume monté — vérifiez que le volume est bien déclaré avant de supprimer le conteneur.
Vérifier la version dans le conteneur
Connectez-vous au conteneur et confirmez la version : docker exec -it postgres-container psql -U postgres -c 'SELECT version();'. La sortie doit indiquer la version corrigée.
Mesures de contournement si le patch est temporairement impossible
Si vous ne pouvez pas redémarrer l'instance immédiatement, trois mesures réduisent l'exposition à CVE-2026-6471 sans appliquer le correctif :
Premièrement, révoquer l'attribut REPLICATION des comptes qui n'en ont pas besoin (ALTER ROLE nom NOREPLICATION;). Deuxièmement, restreindre les entrées de réplication dans pg_hba.conf aux seules adresses IP des pairs légitimes — remplacer une règle host replication all 0.0.0.0/0 par des entrées spécifiques à chaque hôte autorisé. Troisièmement, si votre instance n'utilise pas la réplication logique du tout, vous pouvez passer wal_level = replica (au lieu de logical) dans postgresql.conf — cette configuration désactive le décodage logique et ferme le vecteur d'attaque de CVE-2026-6471.
Pour CVE-2026-14669, aucun contournement applicatif n'est documenté : le seul remède est la mise à jour du binaire.
Vérifier les applications qui embarquent PostgreSQL
Supabase, NocoDB, Gitea, Twenty CRM et Planka embarquent PostgreSQL dans leurs images Docker ou leurs charts Helm. Pour ces applications, la mise à jour PostgreSQL passe par la mise à jour de l'image de l'application elle-même. Vérifiez les notes de version de chaque application : depuis le 13 août 2026, les distributions qui ont publié une mise à jour doivent avoir intégré PostgreSQL 17.11, 16.15 ou équivalent. Si aucune mise à jour n'est disponible pour votre application, vous pouvez déployer un conteneur PostgreSQL séparé à la version corrigée et pointer l'application dessus — ou épingler l'image postgres de base dans votre docker-compose.yml à la version corrigée, si l'architecture le permet.
La commande SELECT version(); dans psql ne suffit pas pour confirmer que le correctif est actif si plusieurs binaires PostgreSQL coexistent sur le même hôte. Vérifiez quel binaire tourne réellement : pg_lsclusters sur Debian/Ubuntu liste tous les clusters avec leur version. Assurez-vous que le cluster actif utilise bien le binaire mis à jour, et pas un binaire résiduel d'une installation précédente.
Déployer PostgreSQL avec accès root pour appliquer les correctifs à la main
Sur un hébergement mutualisé ou dans un environnement PaaS, vous n'avez pas accès au binaire PostgreSQL : la mise à jour dépend de votre fournisseur. Sur un VPS avec accès root, vous appliquez ce correctif en moins de dix minutes, sans dépendre d'un tiers. Vous choisissez le moment du redémarrage, vous gardez la main sur pg_hba.conf, et vous auditez vous-même vos rôles de réplication. C'est le modèle qui s'applique naturellement à toute stack auto-hébergée.
