Contexte de la découverte

En août 2026, l’auteur a découvert une faille de type‑confusion dans le cœur de PostgreSQL, remontant à 2004, soit plus de deux décennies. La vulnérabilité, identifiée sous le numéro CVE‑2026‑6460, provient d’un primitive de gestion des Datum qui n’a jamais été corrigé. Elle a été mise en lumière alors que l’auteur travaillait sur l’extension pg_clickhouse, qui traduit les valeurs ClickHouse en valeurs PostgreSQL. Un défaut de conversion a déclenché une chaîne d’écriture hors‑bande (OOB) et de lecture, menant à l’exécution de code à distance.

Mécanisme de confusion de type

PostgreSQL représente chaque valeur interne par un Datum de 8 octets. Le type réel est stocké séparément dans la colonne consttype, qui contient l’OID du type (par ex. 23 pour int4). Le tableau suivant montre la structure d’un Datum contenant l’entier 1337 :

{QUERY
   :commandType 1
   :targetList (
      {TARGETENTRY
         :expr
            {CONST
               :consttype 23 
               :consttypmod -1 
               :constlen 4 
               :constbyval true 
               :constisnull false 
               :location 7 
               :constvalue 4 [ 57 5 0 0 0 0 0 0 ]
            }
      }
   )
}

Les octets 57 5 0 0 (0x39 05) correspondent à 1337 en little‑endian, tandis que les quatre octets supérieurs restent à zéro car le Datum est déclaré « by value ». Lorsque le même Datum représente un type variable comme text, le champ typbyval vaut false et les 8 octets contiennent alors un pointeur vers la zone mémoire du texte. Cette dualité permet à un attaquant de modifier le consttype après l’initialisation du Datum, forçant le moteur à interpréter les mêmes 8 octets comme un pointeur valide alors qu’ils contiennent en réalité une valeur entière.

Exploitation et impact

En injectant une valeur composite, l’auteur a pu changer dynamiquement le type d’un champ, puis demander à PostgreSQL de le relire. La lecture déclenche un accès mémoire non contrôlé, aboutissant à une corruption fiable du heap. La chaîne d’exploitation repose sur deux étapes : (1) écriture hors‑bande via pg_clickhouse (corrigée en juin 2023) pour placer le Datum manipulé, et (2) relecture avec le type falsifié pour déclencher le débordement. Le résultat est une exécution de code arbitraire avec les privilèges du processus serveur PostgreSQL, typiquement l’utilisateur postgres du système d’exploitation.

Le caractère « ancien » du primitive signifie que toute version de PostgreSQL antérieure à la correction (non encore publiée au moment de la rédaction) est potentiellement vulnérable. Les déploiements managés qui utilisent des versions non patchées sont donc exposés, d’où l’appellation « Managed PostgreSQL » dans le titre de la série de blogs.

Limites et recommandations

Le rapport indique que la chaîne d’exploitation dépend d’une configuration où les extensions tierces peuvent convertir des types externes en Datum sans validation stricte. Les environnements qui désactivent les extensions non essentielles ou qui appliquent le principe du moindre privilège réduisent la surface d’attaque. En attendant un correctif officiel, il est recommandé de mettre à jour toutes les extensions, de surveiller les journaux de debug_print_parse pour détecter des changements de consttype inattendus, et d’appliquer les correctifs de sécurité publiés par le projet PostgreSQL dès qu’ils sont disponibles.