pgAdmin 4 ajoute un panneau LLM et hérite d'un LFI+SSRF classique (CVE-2026-7817)

De quoi parle-t-on ?

Le 11 mai 2026, le projet pgAdmin a divulgué CVE-2026-7817, un duo de bugs dans les points de configuration de l’API LLM livrés avec pgAdmin 4 9.13 et 9.14. Le rapporteur, crédité sous le nom j3seer, a constaté que deux préférences utilisateur — api_key_file et api_url — étaient passées au client LLM sans validation. Un utilisateur authentifié peut alors lire n’importe quel fichier accessible au processus serveur (local file inclusion) et forcer le serveur à émettre des requêtes HTTP vers des cibles internes telles que les services de métadonnées cloud (server-side request forgery). Le correctif est arrivé dans pgAdmin 4 9.15 via le commit 24485fe96.

La classe de bug a quarante ans. Ce qui est neuf, c’est la surface : le panneau LLM de pgAdmin — un assistant pour la rédaction de requêtes — sert de pont vers le réseau et le système de fichiers. Au fur et à mesure que les produits historiques ajoutent des panneaux « interrogez l’assistant » en 2026, ce type exact de découverte va se répéter.

Comment ça marche

Le panneau LLM permet à l’utilisateur de pointer pgAdmin vers un point de terminaison compatible OpenAI en configurant deux valeurs : une URL pour la base de l’API et un chemin vers un fichier contenant la clé. Les deux sont stockés comme préférences utilisateur et consommés par le chemin de chat et les points de listage des modèles.

La forme vulnérable, simplifiée à partir de l’issue GitHub et du correctif 9.15 :

# Vulnérable (< 9.15) — pseudo-code de la construction du client LLM
api_url      = preferences.get("llm.api_url")        # chaîne arbitraire
api_key_path = preferences.get("llm.api_key_file")   # chemin arbitraire

with open(api_key_path, "r") as f:        # LFI : tout fichier lisible par pgAdmin
    api_key = f.read()

client = OpenAIClient(base_url=api_url,   # SSRF : toute URL, y compris
                      api_key=api_key)    #        http://169.254.169.254/...

Deux comportements atteignables en découlent :

1. LFI via api_key_file. Le chemin est ouvert par le compte de service pgAdmin. Le contenu est ensuite remis au client provider en tant que clé d’API. La manière naturelle d’observer la lecture, c’est le chemin d’erreur — une clé malformée déclenche une réponse qui confirme que la lecture a eu lieu, et dans certaines configurations en renvoie un fragment. Pointer le champ vers une configuration de compte de service, une clé privée ou un fichier de credentials suffit à confirmer l’exfiltration.
2. SSRF via api_url. La chaîne est utilisée telle quelle comme URL de base pour le HTTP sortant. La régler sur http://169.254.169.254/latest/meta-data/iam/security-credentials/ sur un pgAdmin hébergé dans le cloud force le serveur à récupérer les credentials de métadonnées d’instance pour le compte de l’attaquant. Les points de chat et de listage des modèles atteignent tous deux ce chemin de code.

L’exploitation requiert une authentification, ce qui maintient le CVSS à 6.5 (CVSS 3.1) / 7.1 (CVSS 4.0). Sur une instance pgAdmin avec auto-inscription, un mapping SSO laxiste, ou un compte de faible privilège fuité, ce prérequis est facile.

Le correctif 9.15 est court et mérite d’être lu. Il fait trois choses à la frontière des préférences LLM : il confine api_key_file au stockage privé de l’utilisateur (mode serveur) ou au répertoire home (mode desktop), il impose un format ASCII imprimable et plafonne la lecture à 1024 octets, et il filtre api_url contre une nouvelle allow-list (config.ALLOWED_LLM_API_URLS) vérifiée à chaque point d’entrée.

Pourquoi c’est important

Trois points, par ordre de fréquence d’apparition en 2026.

D’abord, le panneau LLM rapporté est une nouvelle surface d’attaque pour de vieux bugs. pgAdmin a livré une petite fonctionnalité d’IA et a hérité d’un CWE-552 (LFI) et d’un CWE-918 (SSRF) à la jointure. Le même motif apparaît dans l’outillage de bases de données, les IDE, les systèmes de tickets et les tableaux de bord d’observabilité, à mesure que chacun ajoute « configurez votre fournisseur LLM ici ». Tout champ de préférence qui atteint un open() ou un client HTTP sans validation est un candidat.

Ensuite, authentifié ne signifie pas sûr. Le rôle pgAdmin requis pour modifier les préférences LLM est détenu par quiconque peut se connecter et éditer ses propres paramètres. Pour un pgAdmin multi-locataire derrière du SSO — forme courante en fintech et en plate-forme — l’attaquant pratique est n’importe quelle identité d’entreprise avec une raison de pointer un outil vers son propre onglet pgAdmin.

Enfin, le SSRF vers les métadonnées cloud reste le pivot post-authentification au plus haut rendement sur les flottes PostgreSQL gérées. Si pgAdmin tourne dans EC2, GCE ou AKS avec un rôle d’instance attaché, le SSRF lit les credentials STS du rôle. Ces credentials lisent ensuite le secret de la base, le bucket des snapshots RDS, et tout ce que le rôle peut atteindre. CVE-2026-7817 est intéressante moins pour ce qu’elle est que pour l’environnement dans lequel elle s’insère.

C’est le même motif déjà signalé plus tôt en 2026 dans LMDeploy CVE-2026-33626 (SSRF dans un serveur d’inférence) et LiteLLM CVE-2026-42208 (SQLi dans un proxy LLM) : des vulnérabilités web classiques dans des logiciels qui n’existaient pas il y a trois ans, à proximité immédiate des credentials et du trafic des modèles.

Défenses

1. Passez à pgAdmin 4 9.15 ou supérieur. Le correctif figure dans les notes de version 9.15 et est bundle avec sept autres correctifs de sécurité (CVE-2026-7813 à CVE-2026-7820) dans la même release. Ne sélectionnez pas celui-ci à part.
2. Auditez les préférences LLM existantes avant la mise à niveau. Extrayez la table des préférences de votre base pgAdmin et cherchez les api_key_file pointant hors de la zone de stockage utilisateur et les api_url qui ne sont pas https://api.openai.com, https://api.anthropic.com, ou le fournisseur que vous utilisez réellement. Tout le reste est soit une mauvaise configuration, soit une preuve d’exploitation.
3. Définissez config.ALLOWED_LLM_API_URLS explicitement. Une fois en 9.15, déclarez l’allow-list dans config_local.py avec les deux ou trois points de terminaison fournisseurs que votre équipe utilise vraiment. Les valeurs par défaut sont conservatrices, mais la valeur du contrôle vient de sa précision.
4. Bloquez la sortie de pgAdmin vers RFC1918 et lien-local. Sur un pgAdmin hébergé dans le cloud, refusez le trafic sortant depuis l’hôte pgAdmin vers 169.254.0.0/16, 127.0.0.0/8 et les plages RFC1918 pertinentes, sauf vers la base de données elle-même. Cela neutralise l’impact du SSRF même si une variante future passe à travers l’allow-list. Sur AWS, préférez IMDSv2 avec une limite de hops de 1 pour qu’une requête côté serveur ne puisse pas atteindre le service de métadonnées en premier lieu.
5. Exécutez pgAdmin sous un utilisateur dédié à faibles privilèges. Le vecteur LFI ne lit que ce que le processus pgAdmin peut lire. Un compte de service dont le répertoire home est vide et dont les groupes ne comportent ni ssl-cert, ni shadow, ni le chemin des credentials cloud-init, dépouille la primitive de lecture de l’essentiel de sa valeur.
6. Généralisez la leçon à vos propres panneaux LLM. Si vous livrez un produit avec une page « ajoutez votre fournisseur LLM », traitez l’URL d’API comme toute autre URL contrôlée par l’utilisateur passée à un client HTTP (allow-list du schéma, de l’hôte, du port ; résolvez une fois, épinglez), et traitez le chemin de la clé comme tout autre chemin contrôlé par l’utilisateur (confinez-le à un répertoire utilisateur, plafonnez la longueur de lecture, refusez les liens symboliques). Le correctif pgAdmin 9.15 est une forme de référence utilisable.

Statut

Élément	Référence	Date	Notes
Issue déposée	pgAdmin GitHub #9900	2026-05-01	Rapportée par j3seer
CVE assignée	CVE-2026-7817	2026-05-11	Publiée au NVD
pgAdmin 4 9.15 publié	projet pgAdmin	2026-05-11	Huit correctifs de sécurité au total
Commit du correctif	24485fe96	2026-05-11	Allow-list + confinement de chemin + format ASCII
Note d’éditeur	SentinelOne	2026-05-18	Inclut des conseils de détection
Sévérité	NVD	—	CVSS 3.1 : 6.5 / CVSS 4.0 : 7.1
Versions affectées	projet pgAdmin	—	9.13 ≤ version < 9.15

La bonne lecture n’est pas « pgAdmin avait un bug ». C’est « la frontière de configuration LLM devient un endroit standard pour trouver du LFI et du SSRF dans les produits matures, et les motifs de validation pour la défendre sont désormais connus ». Appliquez le correctif ; puis appliquez le motif.