La vulnérabilité PostgreSQL CVE-2026-6460 permet à un utilisateur capable de créer des objets dans la base d'exécuter du code sous l'identité du compte système qui fait fonctionner PostgreSQL. Le correctif est disponible dans les versions 18.7, 17.12, 16.16, 15.20 et 14.25. Pour une petite équipe SaaS, un détail est décisif : la seule mise à jour du serveur peut laisser le travail inachevé. PostgreSQL précise qu'une protection complète exige aussi de recompiler les extensions écrites en C, dont certaines nécessitent une modification du code source. Vérifiez le déploiement actif et ses extensions avant de clore la remédiation. ([Avis de sécurité](https://www.postgresql.org/support/security/CVE-2026-6460/), [notes de version](https://www.postgresql.org/docs/17/release-17-12.html).)

Un ingénieur met à jour l'image de la base, l'application se reconnecte et le ticket semble prêt à être clos. C'est un premier résultat utile. Une question reste pourtant ouverte : le système déployé comprend-il toutes les composantes du correctif ?

Avec cette version, la question se pose très concrètement. Le serveur vérifie désormais les valeurs composites dont la disposition ne correspond plus au type utilisé pour les interpréter. Les extensions natives interviennent dans ce mécanisme. Un redémarrage réussi et le numéro de version attendu ne suffisent pas à établir qu'elles ont été recompilées correctement.

Il faut donc réunir assez de preuves pour préciser ce qui a été mis à jour, ce qui fonctionne réellement et ce qui reste incertain. Vous pouvez le faire sans transformer une mise à jour mineure de sécurité en migration de base de données inutile.

## Déterminez les accès nécessaires à l'exploitation

La condition indiquée dans l'avis — pouvoir créer des objets dans la base — doit guider l'évaluation de l'exposition. Une personne disposant de ce droit n'a pas le même accès à PostgreSQL qu'un client qui utilise uniquement les formulaires de l'application.

Pour votre déploiement, identifiez qui peut se connecter à la base et y créer des objets : rôles applicatifs, rôles de migration, développeurs, automatisations et éventuels accès SQL proposés aux clients. Tenez compte des droits effectifs obtenus par l'appartenance à d'autres rôles. Si des utilisateurs moins dignes de confiance disposent de ces capacités, signalez-le à la personne qui planifie le correctif.

Cet inventaire des accès ne constitue pas une mesure de protection complète. Ne supposez pas que bloquer une seule opération SQL suffit ; PostgreSQL décrit plusieurs voies d'exploitation par le langage de définition de données, ou DDL. De même, une version vulnérable du serveur ne prouve pas, à elle seule, qu'un visiteur non authentifié peut exploiter votre application SaaS. Il faut établir comment ce visiteur pourrait obtenir les capacités nécessaires dans la base. ([Avis de sécurité PostgreSQL](https://www.postgresql.org/support/security/CVE-2026-6460/).)

Délimitez aussi précisément les conséquences. Exécuter du code sous le compte système de PostgreSQL est grave. L'accès à l'administration de l'hôte, aux données d'un autre locataire ou à un autre service dépend cependant du déploiement. Aucun de ces résultats supplémentaires ne doit figurer comme un fait établi dans le dossier d'incident sans preuve à l'appui.

Dans une petite équipe, une courte note peut suffire : quelle base, quels rôles, qui est responsable de la mise à jour et quels accès restent à examiner. Si la maintenance doit devenir une réponse à incident, un [plan de réponse à incident d'une page](/blog/solo-founder-incident-response-plan) aide à clarifier les responsabilités.

## Choisissez la version corrigée de votre branche actuelle

L'avis du projet PostgreSQL indique les premières versions mineures corrigées suivantes, publiées le 12 novembre 2026 :

| Branche PostgreSQL | Première version corrigée du projet |
| --- | --- |
| 18 | 18.7 |
| 17 | 17.12 |
| 16 | 16.16 |
| 15 | 15.20 |
| 14 | 14.25 |

Source : [avis CVE-2026-6460](https://www.postgresql.org/support/security/CVE-2026-6460/).

Commencez par la version correspondant à votre branche majeure actuelle. PostgreSQL distingue la mise à jour mineure du changement de version majeure : les versions mineures conservent le format de stockage et nécessitent habituellement l'arrêt du serveur, l'installation des binaires à jour, puis le redémarrage. Le changement de version majeure suit son propre processus de migration. Lisez toujours les notes de version pour connaître les étapes supplémentaires, y compris celles des versions que vous avez sautées. ([Politique de gestion des versions](https://www.postgresql.org/support/versioning/).)

Passer un déploiement PostgreSQL 17 en 17.12 est, par exemple, une opération différente du passage à PostgreSQL 18. Séparez le correctif urgent du changement de version majeure prévu, avec des critères d'acceptation propres à chaque intervention.

Un service géré ou une distribution peut fournir un correctif rétroporté sous un autre identifiant de compilation. Demandez alors une preuve reliant la compilation déployée à cette CVE. Un numéro différent de la version corrigée du projet appelle une vérification ; il ne suffit pas à déclarer le service corrigé ou vulnérable.

## Intégrez les extensions natives à la mise à jour

L'exigence concernant les extensions est le détail qui risque le plus de disparaître entre l'avis de sécurité, la tâche de déploiement et le commentaire de clôture.

Les notes de version de PostgreSQL précisent qu'une protection complète nécessite de recompiler les extensions écrites en C, et que certaines demanderont des modifications du code source. Elles décrivent aussi `composite_type_mismatch`, un paramètre du serveur qui permet de désactiver les nouvelles vérifications, avec des risques pour la sécurité. La compatibilité des extensions et ce paramètre de protection doivent donc figurer dans le dossier du correctif. ([Notes de PostgreSQL 17.12](https://www.postgresql.org/docs/17/release-17-12.html).)

Avant le déploiement, demandez au responsable de l'image, au fournisseur des paquets ou au prestataire de la base comment ses compilations d'extensions tiennent compte du changement. Pour les extensions compilées par votre équipe, désignez la personne chargée de vérifier leur compatibilité et de produire les nouveaux binaires. Ne supposez pas que l'installation du dernier paquet serveur remplace aussi tous les composants natifs qu'il charge.

Vous pouvez dresser un premier inventaire avec ces requêtes SQL en lecture seule :

```sql
SELECT version();
SHOW server_version;
SELECT extname, extversion
FROM pg_extension
ORDER BY extname;
```

Exécutez-les sur le point d'accès de la base que vous souhaitez vérifier. PostgreSQL décrit les informations de version côté serveur dans ses [fonctions d'information système](https://www.postgresql.org/docs/17/functions-info.html) ; la version d'un client installé sur votre ordinateur répond à une autre question.

La liste des extensions permet d'identifier les travaux à prévoir. Les numéros de version ne prouvent pas que les binaires natifs sous-jacents ont été recompilés. Associez cet inventaire à une preuve portant sur le paquet, l'image, la compilation ou le fournisseur et couvrant cette exigence. Si quelqu'un a désactivé les nouvelles vérifications pour faire fonctionner une extension, consignez explicitement cette décision de sécurité encore non résolue.

## Distinguez les opérations du prestataire des preuves attendues par votre équipe

Avec PostgreSQL auto-hébergé, votre équipe peut être responsable de l'artefact serveur, des extensions, du redémarrage et des vérifications applicatives. Pour un service géré, le prestataire peut réaliser l'essentiel de ces opérations. Quelqu'un doit néanmoins être chargé de réunir les preuves de votre côté.

Posez au prestataire une question précise sur votre déploiement : la compilation actuellement utilisée par ce service inclut-elle le correctif CVE-2026-6460, et comment les extensions natives ont-elles été traitées ? Demandez si une intervention du client est nécessaire et si la nouvelle protection est activée. Conservez sa réponse avec l'identifiant du service et le compte rendu de maintenance.

Le [récit technique du chercheur](https://mehmetince.net/part-3-6-how-i-ended-up-turning-a-22-year-old-postgresql-type-confusion-primitive-into-rce-cve-2026-6460/) explique pourquoi les services PostgreSQL gérés faisaient partie de ses recherches. Il n'établit pas l'état actuel des correctifs chez votre prestataire ou sur votre instance. Il fournit le contexte ; les preuves propres au déploiement permettent de clore la tâche.

La même rigueur s'applique à l'infrastructure exploitée par votre équipe. Modifier une référence d'image indique ce que vous comptez déployer. Le compte rendu de déploiement et une requête sur le serveur actif aident à établir le résultat. Répétez la vérification pour les instances et points d'accès concernés : une connexion réussie ne prouve pas que tout le parc est à jour.

## Clôturez la tâche avec un dossier de preuves concis

Un commentaire de clôture utile permet à un autre ingénieur de comprendre le résultat sans reconstituer le déploiement à partir des messages de discussion.

| Question avant clôture | Preuves à joindre |
| --- | --- |
| Qu'avons-nous mis à jour ? | Service ou point d'accès de la base, version précédente, artefact cible ou compilation du prestataire |
| Qu'est-ce qui fonctionne maintenant ? | Résultat de la requête de version côté serveur et compte rendu du déploiement ou de la maintenance effectuée |
| Les extensions natives ont-elles été traitées ? | Inventaire des extensions et preuve d'une recompilation compatible ou confirmation du prestataire |
| La nouvelle protection est-elle active ? | Examen de la configuration, y compris toute décision concernant `composite_type_mismatch` |
| L'application fonctionne-t-elle toujours ? | Résultats de vérifications représentatives adaptées à l'application |
| Quels points restent ouverts ? | Responsable désigné et action prévue pour chaque point non résolu |

Choisissez les vérifications applicatives selon les usages réels du produit : connexion, lecture et écriture de données représentatives, puis fonctions importantes qui dépendent d'extensions. Ce sont des vérifications d'acceptation du changement, pas la preuve que toutes les propriétés de sécurité sont respectées.

Si l'état de compilation d'une extension est inconnu, laissez ce point ouvert. Si le prestataire confirme un rétroportage, conservez sa référence exacte de compilation. C'est le principe de la [vérification des corrections en aval](/blog/revoked-certificates-downstream-remediation) : la modification effectuée et les systèmes qui en dépendent doivent tous être examinés.

Si vous suivez la vulnérabilité dans Kit, le [flux de triage des rapports](/docs/triaging-reports) permet de réunir la responsabilité du rapport, la correspondance et la décision humaine de vérification du correctif. L'équipe infrastructure ou le prestataire fournit les preuves sur lesquelles repose cette décision.

## Gardez les autres suites de la mise à jour visibles

La version de novembre comprend aussi des correctifs qui ont leurs propres exigences de maintenance. Consultez les notes de migration de la branche concernée pour les réparations d'index et les actions sur les sauvegardes à effectuer selon votre situation. Pour les équipes qui utilisent des sauvegardes incrémentales, PostgreSQL recommande expressément de réaliser une nouvelle sauvegarde complète après la mise à jour et de l'utiliser comme base des sauvegardes incrémentales suivantes. Ces interventions découlent de la mise à jour ; elles ne signifient pas que CVE-2026-6460 a corrompu les index ou les sauvegardes. ([Annonce de la version](https://www.postgresql.org/about/news/postgresql-187-1712-1616-1520-1425-and-19-rc-2-released-3442/).)

PostgreSQL 14 impose une autre décision : 14.25 est sa dernière version et le projet a annoncé sa fin de vie. Appliquez le correctif disponible tout en préparant le passage à une version majeure encore maintenue. Attribuez un responsable et un calendrier à cette migration plutôt que de l'intégrer discrètement au correctif urgent.

Terminez le dossier par un état clair des preuves : compilation serveur déployée, état de recompilation des extensions, configuration de la protection et travaux restant à effectuer. L'ingénieur suivant dispose ainsi d'éléments concrets à examiner, et l'équipe d'une justification étayée pour clore la tâche.