CVE-2026-116241 : faille critique pgAdmin 4, injection de commandes via Import/Export

Le 29 octobre 2026, l'équipe pgAdmin a publié la version 9.19 de pgAdmin 4, qui corrige 15 vulnérabilités de sécurité dont CVE-2026-116241, une faille d'injection de commandes système notée 9,9 sur 10 (CVSS v3.1) dans l'outil Import/Export Data. Un utilisateur authentifié disposant du droit tools_import_export_data peut exécuter des commandes shell arbitraires sur le serveur hébergeant pgAdmin, en contournant la protection de la commande \copy de psql. Cette faille est un contournement du correctif de CVE-2026-17566, corrigée en juillet 2026 dans la version 9.17. Tout administrateur qui utilise ce panel d'administration pour gérer ses bases de données PostgreSQL sur un VPS Linux ou un serveur dédié doit mettre à jour sans attendre.

Source : notes de version pgAdmin 4 v9.19 (29 octobre 2026). Références : CVE-2026-116241, CVE-2026-17566, issue GitHub pgadmin-org/pgadmin4 #10663.

Qui est concerné par CVE-2026-116241

pgAdmin 4 est le panel d'administration web de référence pour PostgreSQL. Il est utilisé par les administrateurs de bases de données pour gérer leurs instances depuis un navigateur : exécuter des requêtes SQL, importer ou exporter des données, gérer les rôles et les permissions, surveiller les logs de performance. pgAdmin est déployé sur des serveurs Linux (Ubuntu, Debian, Rocky Linux) et sous Windows, souvent aux côtés de PostgreSQL lui-même ou sur un poste d'administration dédié connecté au serveur de base de données.

Les profils directement exposés sont :

• Les administrateurs de VPS et de serveurs dédiés qui ont installé pgAdmin 4 pour gérer leurs bases PostgreSQL sur un serveur virtuel ou une machine bare-metal, que ce soit un serveur de production, un environnement de développement ou une instance hébergeant les données d'un serveur de jeu ;
• Les équipes qui déploient pgAdmin via Docker (image officielle dpage/pgadmin4) sur un VPS avec Docker, exposant l'interface derrière un reverse proxy Nginx ou Apache ;
• Les hébergeurs et prestataires d'infogérance qui mettent une interface pgAdmin à disposition de leurs clients pour administrer des bases PostgreSQL mutualisées ou dédiées.

Le serveur web qui héberge pgAdmin cohabite souvent avec d'autres services : MySQL ou MariaDB pour les applications PHP, un serveur SMTP pour l'envoi de mails, un accès FTP pour les transferts de fichiers, un serveur DNS local. Si un attaquant obtient l'exécution de commandes via pgAdmin, il accède potentiellement à l'ensemble de ces services, à leurs fichiers de configuration et aux données qu'ils contiennent, y compris les sauvegardes stockées sur le même serveur.

Si votre installation pgAdmin 4 est antérieure à la version 9.19, elle est vulnérable. L'attaque nécessite un compte utilisateur pgAdmin avec le droit d'utiliser l'outil Import/Export Data, un droit activé par défaut pour tous les utilisateurs.

Comment fonctionne la vulnérabilité

L'outil Import/Export Data de pgAdmin permet d'exporter les résultats d'une requête SQL vers un fichier sur le disque du serveur. En interne, pgAdmin construit une ligne de commande psql \copy (...) TO en y interpolant la requête SQL saisie par l'utilisateur dans le panel. Pour empêcher une injection, pgAdmin vérifie que les parenthèses de la requête sont équilibrées : si un attaquant ferme prématurément la parenthèse, il pourrait injecter une clause TO PROGRAM qui exécute un script ou une commande shell arbitraire sur le serveur.

La première faille (CVE-2026-17566, corrigée dans pgAdmin 4 v9.17 en juillet 2026) exploitait un comportement d'échappement dans les chaînes à guillemets simples. Un backslash dans une chaîne comme SELECT 'a\') TO PROGRAM '...' trompait la vérification des parenthèses : pgAdmin interprétait \' comme un guillemet échappé, alors que psql (avec le paramètre par défaut standard_conforming_strings = on) traitait le backslash comme un caractère littéral. Le guillemet fermait la chaîne, la parenthèse fermait le bloc \copy, et la clause TO PROGRAM s'exécutait avec les droits Unix du processus pgAdmin sur le serveur.

Le correctif de la v9.17 a rejeté les backslashs dans les chaînes à guillemets simples. Mais la vérification ne couvrait pas les identifiants entre guillemets doubles. Un attaquant pouvait placer un backslash dans un identifiant entre guillemets doubles pour tromper la garde de la même manière. C'est CVE-2026-116241 : un contournement du correctif initial, avec le même impact (exécution de commandes root ou de scripts sur le serveur pgAdmin) et le même score critique de 9,9/10.

Le correctif de pgAdmin 4 v9.19 rejette désormais les backslashs dans les guillemets doubles et dans les noms de schéma, table et colonne transmis à \copy.

Versions touchées et correctifs disponibles

Les deux CVE concernent l'outil Import/Export Data. Le tableau ci-dessous résume les versions affectées, les correctifs et les packages à mettre à jour :

La version 9.19 corrige également 14 autres vulnérabilités (CVE-2026-116238 à CVE-2026-116252), incluant des contournements d'authentification et de la limite de tentatives de connexion, des fuites de mots de passe dans les variables d'environnement des processus, l'utilisation des identifiants Kerberos ou du fichier de mots de passe du compte de service pgAdmin par libpq, et des accès non autorisés aux fichiers via des liens symboliques. La migration vers la version 9.19 est la seule action recommandée.

Sauvegarder avant la mise à jour

Avant de lancer la migration vers pgAdmin 4 v9.19, sauvegardez vos configurations et vos données pour pouvoir revenir en arrière en cas de problème. Exportez d'abord la configuration de pgAdmin depuis la ligne de commande :

cp -r ~/.pgadmin/ ~/backup-pgadmin-$(date +%Y%m%d)/

Si pgAdmin est installé en mode serveur (multi-utilisateurs), sauvegardez aussi sa base SQLite interne et ses fichiers de configuration dans /var/lib/pgadmin/. Profitez de cette étape pour réaliser un dump de vos bases PostgreSQL avec pg_dump ou pg_dumpall : une sauvegarde complète avant toute intervention sur le serveur reste une bonne pratique, surtout quand la faille permettait l'exécution de commandes avec les droits du processus. Pour automatiser vos sauvegardes PostgreSQL ou MySQL, consultez notre guide sauvegardes automatisées avec mysqldump et cron (la logique s'applique aussi à pg_dump).

Comment vérifier et mettre à jour pgAdmin 4

Commencez par identifier la version installée. Connectez-vous à l'interface web du panel pgAdmin et consultez le menu Help > About pgAdmin 4, ou exécutez la commande suivante en ligne de commande si pgAdmin est installé via pip :

pip show pgadmin4 | grep Version

Pour une installation Docker, vérifiez le tag de l'image :

docker inspect dpage/pgadmin4 --format '{{ index .Config.Labels "org.opencontainers.image.version" }}'

Mise à jour via pip (installation Python)

pip install --upgrade pgadmin4

Mise à jour via le dépôt APT (Ubuntu, Debian)

sudo apt update
sudo apt install --only-upgrade pgadmin4

Mise à jour Docker

docker pull dpage/pgadmin4:latest
docker compose down && docker compose up -d

Sous Windows

Téléchargez le package d'installation (MSI) de pgAdmin 4 v9.19 depuis le site officiel et lancez l'installateur. Il remplace automatiquement la version précédente. Redémarrez le service pgAdmin depuis les services Windows ou en ligne de commande avec net stop pgAdmin4 && net start pgAdmin4.

Après la mise à jour, vérifiez que la version affichée est bien 9.19 ou supérieure. Si pgAdmin fonctionne comme un service système sur Linux, redémarrez-le pour que le nouveau package soit pris en compte :

sudo systemctl restart pgadmin4

Si vous gérez vos bases PostgreSQL depuis un VPS Linux, profitez de cette intervention pour vérifier que PostgreSQL lui-même est correctement sécurisé (authentification, droits d'accès, adresse IP d'écoute réseau).

Vérifier les logs après la mise à jour

Avant de considérer la migration terminée, vérifiez que pgAdmin fonctionne correctement et qu'aucune exploitation n'a eu lieu. Consultez les logs de pgAdmin pour repérer des erreurs de démarrage ou des requêtes suspectes :

sudo journalctl -u pgadmin4 --since "1 hour ago" --no-pager

Si pgAdmin écrit ses logs dans un fichier (configuration par défaut sous /var/log/pgadmin/), recherchez les lignes contenant PROGRAM ou \copy qui indiqueraient une tentative d'exploitation de la faille :

grep -i "PROGRAM\|\\\\copy" /var/log/pgadmin/pgadmin4.log

Vérifiez également les logs système du serveur pour détecter des processus lancés par l'utilisateur Unix qui exécute pgAdmin et qui ne devraient pas exister (scripts inconnus, connexions réseau sortantes inhabituelles). Pour une analyse complète des journaux, consultez notre guide analyser les logs de connexion SSH sur Linux. Si vous constatez une activité suspecte, isolez le serveur du réseau, changez tous les mots de passe (comptes root, utilisateurs PostgreSQL, clés SSH) et restaurez depuis une sauvegarde antérieure à la compromission.

Réduire l'exposition de pgAdmin sur votre serveur

La mise à jour corrige la faille, mais ces mesures complémentaires limitent l'impact d'une future vulnérabilité dans pgAdmin ou dans tout autre panel d'administration web déployé sur votre serveur :

• Ne pas exposer pgAdmin directement sur Internet. Configurez votre firewall (UFW ou nftables) pour bloquer le port de pgAdmin (5050 par défaut) depuis les adresses IP non autorisées. Accédez à pgAdmin via un tunnel SSH ou un VPN plutôt que de l'exposer sur le réseau public via un nom de domaine. Si l'accès distant est indispensable, filtrez par adresse IP source dans la configuration du firewall.
• Restreindre les droits des utilisateurs pgAdmin. Désactivez le droit tools_import_export_data pour les comptes qui n'en ont pas besoin. Chaque compte utilisateur devrait avoir les permissions minimales nécessaires. Un utilisateur limité à la consultation ne devrait jamais pouvoir lancer un script d'export.
• Placer pgAdmin derrière un reverse proxy avec authentification. Un reverse proxy Nginx (ou Apache) avec authentification HTTP ajoute une couche de protection supplémentaire avant l'écran de connexion pgAdmin. Configurez le virtual host pour n'accepter que les adresses IP de vos administrateurs.
• Isoler pgAdmin du reste des services. Sur un serveur qui héberge aussi des applications PHP, un serveur MySQL ou MariaDB, un service SMTP ou un accès FTP, exécutez pgAdmin dans un conteneur Docker ou un environnement virtuel dédié (virtualisation légère). Cela limite le rayon d'action d'un attaquant qui exploiterait une faille dans le panel : il n'accède pas directement aux configurations des autres services ni à la RAM du processus principal.
• Activer les mises à jour automatiques de sécurité sur votre serveur pour appliquer rapidement les correctifs des packages système : configurer unattended-upgrades sur Ubuntu et Debian.
• Durcir l'accès SSH au serveur hébergeant pgAdmin : désactiver l'authentification root par mot de passe et restreindre les utilisateurs autorisés.

Questions fréquentes