PostgreSQL et CVE-2018-1058 : pourquoi le search_path reste un risque sous-estime
Une faille tres differente des injections classiques
CVE-2018-1058 reste l une des failles PostgreSQL les plus interessantes a relire parce qu elle ne ressemble pas au stereotype habituel de la base compromise par une seule requete injectable. Le PostgreSQL Global Development Group explique officiellement que le probleme touchait la gestion du search_path et la possibilite pour un utilisateur de creer des objets homonymes capables d influencer les requetes d autres utilisateurs.
Pourquoi c est important
Le sujet est pedagogique parce qu il rappelle qu une base de donnees n est pas seulement une question de chiffrement, de sauvegarde ou de SQL injection. La structure des schemas, des privileges et des resolutions de noms fait partie de la surface de securite.
Le guide officiel PostgreSQL parle explicitement d attaque de type trojan-horse. C est exactement ce qui rend cette faille utile : elle montre comment un comportement par defaut raisonnable dans certains contextes peut devenir dangereux en environnement multi-utilisateur.
Ce que les equipes oublient souvent
Beaucoup d equipes voient PostgreSQL comme un bloc fiable une fois la connexion securisee et les acces limites. Or la confiance se joue aussi a l interieur : qui peut creer quoi dans le schema public, quel search_path est applique, et quels objets sont resolus en priorite.
La lecon pour 2026
La documentation officielle recommande notamment de revoquer CREATE sur le schema public pour PUBLIC et de controler plus finement le search_path. C est un rappel tres concret : la securite d une base ne se limite pas a fermer le port 5432.
Notre lecture
Si vous cherchez un CVE representatif du risque base de donnees moderne, CVE-2018-1058 est excellent parce qu il parle de confiance interne et de modelisation des privileges. Ce n est pas une faille spectaculaire au sens marketing. C est mieux : c est une faille qui apprend quelque chose de durable sur la maniere dont une base peut etre utilisee contre ses propres utilisateurs.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
Injection SQL : exemples concrets et défenses modernes
Comment fonctionne une injection SQL en 2026, les variantes (union, blind, time-based), et les protections réelles au-delà des requêtes préparées.
Go et Kubernetes : pourquoi CVE-2018-1002105 reste une reference
CVE-2018-1002105 a touche le kube-apiserver et reste l un des CVE les plus marquants de l ecosysteme Kubernetes. Voici pourquoi cette faille reste une reference.
Go et Grafana : pourquoi CVE-2021-43798 reste un rappel utile
CVE-2021-43798 a montre qu un produit Go largement deploie pouvait exposer des fichiers locaux via un path traversal. Voici pourquoi ce cas reste utile en 2026.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.