kihara-1/postgresql-cve-2026-14662
Vulnérabilité d'écriture hors limites découverte dans la recherche plein texte de PostgreSQL (tsvector/tsquery), CVE-2026-14662, vérifiée en exécutant côte à côte dans Docker les versions non corrigée (18.4) et corrigée (18.6) : enregistrement des résultats et supports de présentation.
Voici un compte rendu de l'observation réelle des différences de comportement entre la version non corrigée (18.4) et la version corrigée (18.6) de PostgreSQL, exécutées simultanément dans Docker, concernant la CVE-2026-14662 découverte dans les types de données de recherche plein texte (tsvector / tsquery).
Ce document a été préparé à des fins d'apprentissage en cybersécurité et inclut également les supports de présentation.
| Élément | Contenu |
|---|
| CVE | CVE-2026-14662 |
| Cible | tsvector / tsquery de PostgreSQL |
| Type | Taille d'allocation insuffisante due à un dépassement d'entier et écriture hors limites |
| CVSS | 8.8 / 10.0 (High) |
| Date de publication | 2026-08-13 |
| Versions corrigées | 18.5, 17.11, 16.15, 15.19, 14.24 |
La chaîne de faiblesses se présente comme suit.
CWE-190 (dépassement d'entier) → CWE-131 (calcul incorrect de la taille du tampon) → CWE-787 (écriture hors limites)
＝cause racine ＝impact final
.
├── docs/
│ └── presentation.md Supports de présentation (explication de la vulnérabilité + explication des CWE)
└── docker/
├── README.md Mode d'emploi de l'environnement de reproduction
├── docker-compose.yml
├── init/ SQL d'initialisation commun exécuté sur les deux versions
├── test/ PoC et SQL de démonstration
└── run.sh Démarrage → exécution du PoC → affichage des résultats
Si Docker et Docker Compose sont disponibles, il suffit de procéder comme suit pour reproduire.
cd docker
./run.sh
Les conteneurs 18.4 et 18.6 démarrent, le même SQL d'initialisation est injecté, puis le même PoC est exécuté sur les deux et les résultats sont affichés côte à côte. Veuillez consulter docker/README.md pour plus de détails.
| Test | PostgreSQL 18.4 (non corrigé) | PostgreSQL 18.6 (corrigé) |
|---|---|---|
| Répétition de l'auto-jointure OR de tsquery | Réussite sans erreur jusqu'à 18 fois (8 650 748 octets au final) | ERROR: tsquery is too large à la 17e fois |
| Tableau de mots d'une longueur totale de 1 200 000 octets | Réussit | ERROR: string is too long for tsvector (1200000 bytes, max 1048575 bytes) |
| Un seul mot de 3 000 octets | Réussit | ERROR: word is too long (3000 bytes, max 2046 bytes) |
Avant la correction, les données dépassant la limite de la représentation interne (MAXSTRPOS = 1 048 575, issu d'un champ de bits de 20 bits) étaient acceptées sans la moindre erreur.
À noter que la raison pour laquelle 18.6 s'arrête « exactement à la 17e fois » peut être expliquée par le calcul, et nous avons confirmé que la valeur théorique et la valeur mesurée correspondent octet pour octet (voir les supports de présentation pour plus de détails).
Pour vérifier les différences, nous avons utilisé un clone du dépôt officiel de PostgreSQL, mais comme il est volumineux (185 Mo chacun), il n'est pas inclus dans ce dépôt. Si nécessaire, récupérez-le comme suit.
git clone --branch REL_18_4 --depth 1 https://github.com/postgres/postgres.git postgres-18.4
git clone --branch REL_18_6 --depth 1 https://github.com/postgres/postgres.git postgres-18.6
Les trois fichiers modifiés sont les suivants.
src/backend/utils/adt/tsquery_util.csrc/backend/utils/adt/tsvector.csrc/backend/utils/adt/tsvector_op.c