Montargis, le 14 août 2025

Le PostgreSQL Global Development Group a publié le 14 août une mise à jour pour toutes les versions supportées de PostgreSQL, c’est-à-dire les versions 17.6, 16.10, 15.14, 14.19 et 13.22, ainsi que la troisième bêta de la version 18. Cette mise à jour corrige 3 failles de sécurité et plus de 55 bugs remontés ces derniers mois. Si vous avez créé un index BRIN avec la classe d’opérateur numeric_minmax_multi_ops, voir la partie « Mise à jour » pour des opérations post-mise à jour.

visuel annonce

Annonce de fin de vie de PostgreSQL 13

PostgreSQL 13 ne recevra plus de mises à jour après le 13 novembre 2025. Si vous utilisez PostgreSQL 13 en production, nous vous conseillons de planifier la migration vers une version plus récente et supportée. Voir la politique de versionnement pour plus de détails.

Sécurité

  • CVE-2025-8713 : Les statistiques de l’optimiseur peuvent exposer des échantillons de données dans une vue, une partition ou une table fille.
    CVSS v3.1 Base Score : 3.1
    Version supportées vulnérables : 13 - 17

    Les statistiques de l’optimiseur permettent à un utilisateur d’accéder à des échantillons de données pour des vues auxquelles l’utilisateur n’a normalement pas accès. Ces statistiques permettent aussi à un utilisateur de lire des échantillon de données concernant des lignes normalement masquées par la politique de sécurité au niveau des lignes (RLS). PostgreSQL maintient ses statistiques en échantillonnant les données des colonnes. Ces données sont consultées pendant la phase de planning des requêtes. Avant cette mise à jour, un utilisateur pouvait créer un opérateur pouvant divulguer des données en ignorant les droits sur les vues (ACL) et les politiques de sécurité au niveau des lignes (RLS) sur les tables et hiérarchies de tables. Les données visibles incluaient notamment les histogrammes et les listes de valeurs les plus courantes. Les CVE-2017-7484 et CVE-2019-10130 visaient à corriger ce type de vulnérabilité, mais le souci persistait. Les versions avant PostgreSQL 17.6, 16.10, 15.14, 14.19, et 13.22 sont concernées par ce problème.

    Le projet PostgreSQL remercie Dean Rasheed d’avoir rapporté ce problème.

  • CVE-2025-8714 : pg_dump permet au super utilisateur du serveur d’origine d’exécuter du code dans un client psql
    CVSS v3.1 Base Score : 8.8
    Version supportées vulnérables : 13 - 17

    Une sélection de données non fiable dans pg_dump permet à un superutilisateur malveillant du serveur d’origine d’injecter un code arbitraire, qui sera exécuté au moment de la restauration, en tant que compte du système d’exploitation client exécutant psql pour restaurer le dump, via les méta-commandes psql. pg_dumpall est aussi affecté par ce problème. pg_restore est affecté également, si on l’utilise pour générer un dump au format texte. Cette vulnérabilité est similaire au CVE-2024-21096 concernant MySQL. Les versions précédant PostgreSQL 17.6, 16.10, 15.14, 14.19, and 13.22 sont concernées.

    Le projet PostgreSQL remercie Martin Rakhmanov, Matthieu Denais, et RyotaK d’avoir rapporté ce problème.

  • CVE-2025-8715 : pg_dump : un saut de ligne dans le nom d’un objet permet d’exécuter du code dans le client psql et sur le serveur cible d’une restauration.
    CVSS v3.1 Base Score : 8.8
    Version supportées vulnérables : 13 - 17

    Un neutralisation incorrecte des sauts de lignes dans pg_dump permet à un utilisateur du serveur d’origine d’injecter du code exécuté lors de la restauration en utilisant le compte du système d’exploitation client qui restore le dump, via des méta-commandes psql incluses dans des nom d’objets préparés pour cela. La même attaque permet des injection de SQL en tant que super utilisateur du serveur de la restauration. pg_dumpall, pg_restore et pg_upgrade sont aussi affectés. Les versions précédant PostgreSQL 17.6, 16.10, 15.14, 14.19, et 13.22 sont concernées par ce problème. Les versions précédant la version 11.20 ne sont pas affectées. La CVE-2012-0868 avait corrigé ce type de vulnérabilité, mais la version 11.20 les a réintroduites.

    Le projet PostgreSQL remercie Noah Misch d’avoir rapporté ce problème.

Correctifs et améliorations

Cette mise à jour corrige plus de 55 bugs remontés ces derniers mois. Les problèmes ci-dessous concernent PostgreSQL 17. Certains peuvent concerner d’autres versions supportées.

  • Correction pour les index BRIN utilisant la classe d’opérateurs numeric_minmax_multi_ops, qui peuvent devenir fragmentés et inefficaces. Voir la section « Mise à jour » pour la méthode de correction.

  • Plusieurs correctifs pour la réplication logique, dont un échec d’allocation mémoire, un rejeu de transaction en double, une attente de durée infinie, un arrêt non prévu, et un secondaire incapable de s’arrêter.

  • Correction d’une suppression prématurée de vieux journaux pendant un checkpoint, ce qui pourrait impacter le recovery avec des slots de réplication.

  • Annulation d’un changement pouvant provoquer le rejet de documents XML de plus de 10 Mo.

  • Corrige la manière dont les classes de caractères imbriqués (e.g.[[:alpha]%_]) sont gérées dans les expressions SIMILAR TO.

  • Rétablit la possibilité pour les expressions PL/pgSQL d’utiliser l’exécution en parallèle.

  • Évite un scénario rare où un index B-tree pouvait modifier la mauvaise entrée.

  • Plusieurs correctifs pour MERGE, notamment des résultats de requêtes incorrects en cas de concurrence et lors du ciblage d’une table parent d’une hiérarchie d’héritage.

  • Correction d’un échec de décompression LZ4 pouvant se produire sur des données peu compressibles.

  • Empêche une boucle infinie lors des checkpoints sur les systèmes avec un paramètre shared_buffers très élevé.

  • Correction des problèmes d’authentification GSSAPI lors de l’utilisation de comptes Active Directory avec de nombreux membres de groupes. Cette version corrige aussi les échecs de connexion dépendantes du timing lors de l’utilisation du chiffrement SSL ou GSSAPI en mode non bloquant.

  • Correction d’un crash dans la fonction libpq PQcancelCreate().

  • Correction de plusieurs fuites de ressources.

Mettre à jour

Toutes les mises à jour de PostgreSQL sont cumulatives. Comme pour les autres versions mineures, les utilisateurs n’ont pas besoin de sauvegarder et recharger leur base de données, ni d’utiliser pg_upgrade pour appliquer la mise à jour. Vous pouvez simplement arrêter PostgreSQL et mettre à jour ses binaires.

Si vous avez des index BRIN utilisant la classe d’opérateurs numeric_minmax_multi_ops, il est conseillé de procéder à un REINDEX après la mise à jour pour éviter toute fragmentation ou inefficacité potentielle. Les utilisateurs ayant sauté une version mineure ou plus peuvent avoir besoin de réaliser d’autres opérations post-mise à jour. Voir les notes des versions précédentes pour les détails.

À propos de PostgreSQL 18

Cette mise à jour est aussi la troisième version bêta de PostgreSQL 18 et rapproche la communauté de la publication espérée autour de septembre/octobre 2025. Dans l’esprit de la communauté PostgreSQL et de l’open source, nous vous encourageons fortement à tester les nouvelles fonctionnalités de PostgreSQL 18 sur vos systèmes pour nous aider à éliminer bugs et autres problèmes. Bien que nous vous déconseillions de lancer PostgreSQL 18 bêta 3 en production, nous vous encourageons à trouver des moyens d’y faire tourner votre charge applicative typique. Vos tests et vos retours aideront la communauté à garantir que PostgreSQL 18 assurera les standards pour publier une version stable et fiable de la plus avancée base de données relationnelle open source.

Pour des détails sur la procédure de test en bêta, et comment contribuer : https://www.postgresql.org/developer/beta/

Mettre à jour PostgreSQL 18 bêta 3

Pour mettre PostgreSQL18 à jour depuis une version précédente, vous devez utiliser une stratégie similaire à une migration entre versions majeures de PostgreSQL (par exemple pg_upgrade ou pg_dump/pg_restore). Pour plus de détails, voir la partie de la documentation sur la mise à jour.

Changements depuis la bêta 2 :

Les changement dans la bêta 3 incluent :

  • un correctif pour une régression de performances dans des requêtes triviales
  • un correctif d’une erreur can't get cancellation key observée avec d’autres logiciels
  • un correctif pour des backgrounds workers ne redémarrant pas après des crashs
  • un correctif pour un rare échec d’I/O asynchrone
  • un correctif qui empêche pg_dumpall --statistics-only et --no-schema d’exporter trop d’objets
  • la suppression des formats de sortie non textuels de pg_dumpall
  • un correctif de date_trunc(..., 'infinity'::timestamptz) sur systèmes 32 bits

Merci de voir les notes de version pour la liste complète des nouveautés et changements : https://www.postgresql.org/docs/18/release-18.html

Tester bugs et compatibilité

La stabilité de chaque version de PostgreSQL dépend grandement de vous, la communauté, pour tester la nouvelle version avec votre charge et vos outils de test pour trouver des bugs et des régressions avant la publication de PostgreSQL 18. Comme il s’agit d’une bêta, des changements mineurs du comportement de la base, de détails et des API sont toujours possibles. Vos retours et vos tests aideront à déterminer les ajustements finaux des nouvelles fonctionnalités, donc merci de tester prochainement. La qualité des tests des utilisateurs aide à déterminer quand nous pourrons publier une version finale. Une liste des problèmes ouverts est publiquement disponible sur le wiki PostgreSQL. Vous pouvez y remonter des bugs avec ce formulaire du site web de PostgreSQL : https://www.postgresql.org/account/submitbug/

Planning de la bêta

Il s’agit de la troisième version bêta de la version 18. Le projet PostgreSQL publiera une ou plusieurs versions candidates avant la publication finale aux alentours de septembre/octobre 2025. Pour d’autres détails voir la page Beta Testing

Liens


DALIBO

DALIBO est le spécialiste français de PostgreSQL®. Nous proposons du support, de la formation et du conseil depuis 2005.