La CISA a inscrit une faille Drupal activement exploitée à son catalogue Known Exploited Vulnerabilities et a imposé aux agences fédérales américaines une échéance de correction. Pour les équipes web, devops et RSSI, ce type d’injonction change immédiatement le niveau de priorité opérationnelle : on ne parle plus d’un correctif “à planifier”, mais d’une vulnérabilité déjà observée en exploitation réelle sur des instances exposées à Internet. La faille visée est CVE-2025-3169, une injection SQL affectant le module Drupal core dans certaines branches maintenues. Son score CVSS v3.1 est de 8.1 selon l’avis Drupal, ce qui la place dans une catégorie à fort impact, avec compromission potentielle des données et, selon l’architecture du site et les privilèges applicatifs, possibilité d’aller jusqu’à une prise de contrôle plus large.

Le signal est important au-delà du périmètre fédéral américain. Lorsqu’une vulnérabilité web entre dans le radar de la CISA avec obligation de patch, cela signifie généralement trois choses pour l’écosystème : des preuves d’exploitation existent, des attaquants ont industrialisé au moins une partie du vecteur, et les systèmes exposés non corrigés deviennent des cibles prioritaires. Pour les hébergements mutualisés, VPS et clusters gérés chez OVHcloud, o2switch, Scaleway ou chez des infogérants français, le sujet est particulièrement concret : de nombreuses instances Drupal restent accessibles publiquement, parfois avec un inventaire incomplet des versions, des modules et des chemins d’administration.

La source initiale médiatisant l’alerte est l’article de BleepingComputer sur l’ordre de correction émis par la CISA. La source technique de référence reste toutefois l’advisory officiel Drupal, qui documente les branches affectées et les versions corrigées, ainsi que l’entrée CISA KEV confirmant l’exploitation active. Côté francophone, même en l’absence d’un avis CERT-FR dédié au moment de la rédaction, les organisations soumises à des exigences de sécurité web devraient traiter cette faille comme un incident potentiel tant que l’exposition n’a pas été vérifiée.

Le point critique pour les équipes opérationnelles est simple : toute instance Drupal exposée sur Internet et encore dans une version vulnérable doit être identifiée, priorisée et corrigée rapidement. Le risque n’est pas limité à un simple dysfonctionnement applicatif. Une injection SQL sur un CMS peut permettre l’exfiltration de comptes, de sessions, de contenus non publics, de configurations sensibles, voire la préparation d’une exécution de code indirecte si l’attaquant peut modifier des paramètres, déposer du contenu interprété ou pivoter vers des composants d’administration. L’urgence n’est donc pas seulement technique ; elle touche aussi la gouvernance de patch management, la visibilité de parc et la capacité à distinguer les sites réellement exposés des environnements internes ou déjà protégés.

Versions affectées

Selon l’avis de sécurité officiel de Drupal relatif à CVE-2025-3169, les branches maintenues affectées sont les suivantes :

  • Drupal 11 : versions 11.0.x et 11.1.x avant 11.1.6, ainsi que 11.2.x avant 11.2.1
  • Drupal 10 : versions 10.3.x avant 10.3.13 et 10.4.x avant 10.4.3

Les versions corrigées à cibler sont donc :

  • 11.1.6
  • 11.2.1
  • 10.3.13
  • 10.4.3

Les branches plus anciennes hors support posent un problème supplémentaire. Une instance en 9.x ou sur une branche non maintenue n’entre pas toujours dans la liste des versions officiellement corrigées, mais elle doit être considérée comme à risque élevé pour deux raisons : d’une part, elle ne bénéficie plus du cycle normal de sécurité ; d’autre part, les techniques d’exploitation d’une injection SQL dans Drupal ou dans son écosystème sont souvent transposables ou adaptables. Une organisation qui exploite encore une branche obsolète doit engager un plan de migration accéléré, et non se contenter d’une mitigation temporaire.

Pour vérifier la version exacte d’une instance, plusieurs approches sont possibles :

  • via l’interface d’administration Drupal si l’accès est disponible ;
  • via composer show drupal/core sur le serveur ;
  • via drush status si drush est installé ;
  • via l’inventaire CI/CD, les artefacts ou les fichiers composer.lock ;
  • à défaut, via des empreintes HTTP, des métadonnées front-end ou des chemins typiques, avec prudence car ces méthodes sont moins fiables.

Exemples de vérification locale :

composer show drupal/core | grep versions

drush status | grep 'Drupal version'

grep '"name": "drupal/core"' -A 5 composer.lock

Dans les environnements d’hébergement externalisés ou multi-tenant, il est recommandé de croiser plusieurs sources : CMDB, dépôts Git, pipelines de déploiement, snapshots d’images, inventaire EDR, et relevés de reverse proxy. C’est souvent à ce stade que des “petites” instances oubliées réapparaissent : microsites de campagne, extranets historiques, plateformes de test publiées par erreur, ou clones de préproduction exposés derrière un DNS secondaire.

La présence de la vulnérabilité dans le catalogue KEV de la CISA justifie une priorisation immédiate des instances exposées publiquement. Une instance vulnérable mais strictement isolée sur un réseau interne reste un sujet sérieux, mais elle n’a pas le même niveau d’urgence qu’un portail accessible depuis Internet, indexé par les moteurs de recherche ou déjà derrière un CDN avec trafic public.

Vecteur d'attaque

CVE-2025-3169 est décrite comme une injection SQL dans Drupal core. Sans entrer dans des détails d’exploitation qui faciliteraient l’abus, le principe reste classique : une entrée applicative insuffisamment neutralisée permet de modifier la structure d’une requête SQL ou d’influencer son exécution. Dans un CMS complexe comme Drupal, ce type de défaut peut se manifester au niveau de paramètres de requête, de filtres, de formulaires, d’API internes ou de composants de construction de requêtes conditionnelles.

Une injection SQL à distance sur un site Drupal exposé peut produire plusieurs niveaux d’impact selon :

  • les privilèges du compte SQL utilisé par l’application ;
  • la séparation, ou non, entre base applicative et autres bases ;
  • la présence de protections WAF, de journalisation et de règles de blocage ;
  • la possibilité d’enchaîner avec des fonctions d’administration Drupal ;
  • la topologie d’hébergement, par exemple conteneur isolé, VM dédiée ou mutualisation.

Les conséquences concrètes les plus plausibles sont :

  • lecture de données : comptes utilisateurs, adresses e-mail, contenus non publiés, tables de sessions, jetons, métadonnées ;
  • altération de données : modification de contenus, création de comptes, changement de paramètres, insertion de payloads ;
  • contournement d’authentification dans certains scénarios indirects ;
  • préparation d’une exécution de code si l’attaquant peut écrire des données exploitées ensuite par un composant applicatif, un moteur de template, un plugin ou une tâche d’administration ;
  • rebond vers d’autres systèmes si des secrets, chaînes de connexion ou clés API sont stockés en base ou en configuration.

Le fait que la CISA parle d’exploitation active est déterminant. En pratique, cela signifie que des scans opportunistes et des attaques ciblées peuvent déjà chercher :

  • des réponses HTTP caractéristiques de Drupal ;
  • des chemins connus, comme /user/login, /admin, /core/ ou des signatures front-end ;
  • des comportements anormaux sur certains paramètres ;
  • des erreurs SQL ou des écarts de temps de réponse révélant une injection exploitable ;
  • des chaînes de déploiement lentes à patcher, notamment sur des sites à faible maintenance.

Pour les équipes web, l’enjeu opérationnel n’est pas seulement de “comprendre la faille”, mais de mesurer le risque de compromission déjà en cours. Une SQLi ne laisse pas toujours des traces évidentes au premier regard. Un site peut continuer à fonctionner normalement tout en ayant subi :

  • une extraction discrète de données ;
  • l’ajout d’un compte administrateur ;
  • la modification de contenus ou de templates ;
  • l’injection de JavaScript côté front ;
  • le dépôt de webshells via une chaîne secondaire.

Exemple de chaîne d’impact réaliste :

  1. un attaquant identifie une instance Drupal vulnérable via son empreinte HTTP ;
  2. il exploite l’injection SQL pour lire certaines tables applicatives ;
  3. il récupère des informations de session, de configuration ou de comptes ;
  4. il crée ou réactive un accès privilégié, ou modifie un contenu permettant une persistance ;
  5. il utilise ensuite l’interface d’administration ou une faiblesse connexe pour déposer du code malveillant.

Ce type de séquence rappelle des précédents marquants de l’écosystème Drupal, notamment Drupalgeddon et les failles critiques qui ont historiquement touché les couches de rendu, de formulaires ou de traitement des requêtes. La comparaison est utile sur le plan défensif : dès qu’une vulnérabilité Drupal exploitable à distance entre en exploitation active, le délai entre divulgation, scan massif et compromission peut être très court. Même si CVE-2025-3169 n’est pas identique à ces failles historiques en termes de mécanisme, le réflexe de réponse doit être similaire : inventaire, patch, recherche de compromission, rotation de secrets si nécessaire.

Un autre point souvent sous-estimé concerne les environnements de production “stables” qui n’ont pas été redéployés récemment. Plus un site Drupal est ancien, plus il cumule des facteurs aggravants : modules additionnels, dette de configuration, comptes techniques oubliés, règles WAF non mises à jour, journaux incomplets, et parfois privilèges SQL trop larges. Dans ces contextes, une injection SQL a plus de chances de déboucher sur un impact systémique.

Impact

Le score CVSS 8.1 reflète un niveau de sévérité élevé, mais il ne raconte pas à lui seul la réalité du risque métier. Pour un portail institutionnel, un site e-commerce, un extranet RH ou une plateforme de publication, l’impact peut être multiple :

  • atteinte à la confidentialité : fuite de données personnelles, de brouillons, de tickets, de formulaires soumis ;
  • atteinte à l’intégrité : modification de pages, de messages, de redirections, de scripts front-end ;
  • atteinte à la disponibilité : corruption de tables, sabotage de contenus, déni de service logique ;
  • impact réglementaire : notification potentielle CNIL si des données personnelles sont compromises ;
  • impact réputationnel : défacement, phishing hébergé sur un domaine légitime, diffusion de malvertising.

Dans un contexte Drupal, la frontière entre “simple vol de données” et “prise de contrôle du site” est souvent mince. Si l’attaquant peut lire la configuration stockée ou injecter des modifications persistantes, il peut parfois :

  • obtenir des accès à des services tiers ;
  • déployer du contenu malveillant diffusé aux visiteurs ;
  • préparer une compromission de la chaîne d’administration ;
  • tirer parti d’un module contrib vulnérable ou d’une mauvaise hygiène des permissions.

Pour les RSSI, l’ajout au catalogue KEV de la CISA doit être interprété comme un indicateur de menace opérationnel. Même si votre organisation n’est pas soumise aux directives fédérales américaines, l’information a une valeur pratique : les groupes d’attaque et les opérateurs opportunistes se concentrent souvent sur les mêmes surfaces exposées. Une faille activement exploitée dans un CMS populaire a un effet d’entraînement rapide sur les campagnes de scan, les botnets de compromission web et les tentatives d’implantation de scripts de fraude.

Comment patcher

La remédiation prioritaire consiste à mettre à jour Drupal core vers une version corrigée. Les branches cibles sont :

  • 10.3.13 pour la branche 10.3.x
  • 10.4.3 pour la branche 10.4.x
  • 11.1.6 pour la branche 11.1.x
  • 11.2.1 pour la branche 11.2.x

Dans la majorité des déploiements modernes, Drupal est géré avec Composer. La procédure standard consiste à mettre à jour les paquets drupal/core-recommended, drupal/core-composer-scaffold et drupal/core-project-message, puis à appliquer les mises à jour de base de données et à vider les caches.

Mise à jour avec Composer

Exemple pour une branche 10.4.x :

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

php vendor/bin/drush updatedb -y

php vendor/bin/drush cache:rebuild

Exemple pour une branche 11.2.x :

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

php vendor/bin/drush updatedb -y

php vendor/bin/drush cache:rebuild

Si le projet n’utilise pas drupal/core-recommended mais drupal/core, adaptez la commande :

composer require drupal/core:10.4.3 --update-with-all-dependencies

Avant déploiement en production :

  • exécuter la mise à jour sur un environnement de préproduction représentatif ;
  • vérifier la compatibilité des modules contrib et thèmes ;
  • contrôler les migrations de schéma via drush updatedb:status ;
  • préparer un plan de retour arrière basé sur snapshot applicatif et sauvegarde de base ;
  • surveiller les performances après cache:rebuild.

Déploiements packagés et OS

Sur certaines distributions ou appliances, Drupal peut être fourni via des paquets du système ou des images maintenues par un hébergeur. Dans ce cas, la mise à jour peut passer par le gestionnaire de paquets ou par une reconstruction d’image. Les commandes exactes dépendent de l’environnement :

apt update && apt upgrade

dnf upgrade

Cependant, dans la plupart des hébergements Drupal professionnels, la version réellement utilisée est pilotée par Composer, pas par apt ou dnf. Il faut donc éviter une fausse impression de sécurité liée à une mise à jour système qui ne toucherait pas l’arborescence applicative déployée.

Exemple de pipeline CI/CD

Une équipe peut intégrer la correction dans sa chaîne de déploiement avec une logique simple :

composer install --no-dev --prefer-dist --optimize-autoloader

php vendor/bin/drush updatedb -y

php vendor/bin/drush cache:rebuild

php vendor/bin/drush config:status

Le point d’attention principal est la priorisation. Toutes les instances Drupal ne se valent pas. L’ordre de traitement conseillé est :

  • sites Internet publics avec authentification ou données sensibles ;
  • portails institutionnels à forte audience ;
  • back-offices accessibles depuis Internet ;
  • préproductions publiées ;
  • sites internes non exposés.

Pour les organisations disposant de nombreux sites, une campagne de patch doit être pilotée comme une opération de sécurité : inventaire, lotissement par criticité, validation accélérée, fenêtre de changement, contrôle post-déploiement et recherche d’IoC.

Détection

Si le patch n’est pas encore appliqué partout, ou si une exposition a pu durer plusieurs jours, la détection devient indispensable. L’objectif est double : identifier les tentatives d’exploitation en cours et repérer les signes de compromission déjà réalisés.

Identifier les instances exposées

Commencez par dresser la liste des applications Drupal accessibles depuis Internet :

  • inventaire DNS et certificats TLS ;
  • reverse proxies, load balancers et CDN ;
  • règles WAF ;
  • CMDB, dépôts Git, projets Composer ;
  • scans internes de surface d’exposition.

Quelques indices techniques peuvent aider à confirmer Drupal :

  • présence de chemins comme /core/, /sites/default/, /user/login ;
  • ressources statiques contenant /core/assets/ ;
  • headers ou signatures HTML spécifiques ;
  • fichiers CHANGELOG.txt ou métadonnées laissés accessibles, quand ils existent encore.

Il faut toutefois éviter de se fier uniquement à l’empreinte externe. De nombreux sites masquent leur stack ou utilisent des frontaux qui brouillent les signatures. La source la plus fiable reste le référentiel de déploiement.

IoC applicatifs et HTTP

Les indicateurs de compromission d’une SQLi sur Drupal peuvent être subtils. Cherchez notamment :

  • pics de requêtes vers des endpoints Drupal inhabituels ;
  • paramètres contenant des caractères de contrôle SQL, des quotes, commentaires, concaténations ou structures anormales ;
  • variations de temps de réponse pouvant suggérer des tests de type time-based ;
  • codes HTTP 500 ou messages d’erreur SQL dans les logs ;
  • requêtes répétées depuis une même IP ou une même ASN sur plusieurs chemins applicatifs.

Exemples de motifs à surveiller dans les journaux HTTP, sans les considérer comme exhaustifs :

'

"

--

/*

sleep(

union select

or 1=1

Ces chaînes peuvent aussi apparaître dans du bruit Internet ou des faux positifs. Le bon réflexe consiste à corréler :

  • les requêtes suspectes ;
  • les erreurs applicatives ;
  • les créations de comptes ;
  • les modifications de contenu ;
  • les connexions d’administration ;
  • les changements de fichiers sur le serveur.

IoC côté Drupal et base de données

Contrôles prioritaires :

  • utilisateurs administrateurs créés récemment ;
  • modifications inattendues dans les tables d’utilisateurs, de sessions ou de configuration ;
  • contenus publiés ou modifiés hors processus normal ;
  • changements dans sites/default/files ou dans les répertoires de thèmes et modules ;
  • fichiers PHP nouveaux ou renommés ;
  • tâches cron ou hooks système anormaux si l’hébergement le permet.

Exemples de vérifications locales :

find web/sites/default/files -type f -mtime -7

find web -type f -name "*.php" -mtime -7

drush user:information --uid=1

drush sql:query "SELECT uid,name,created,access FROM users_field_data ORDER BY created DESC LIMIT 20;"

Sur la base de données, surveillez également :

  • des requêtes lentes ou anormales dans les logs SQL ;
  • des accès depuis des hôtes inattendus ;
  • des privilèges applicatifs excessifs, comme FILE, SUPER ou des droits d’administration non nécessaires ;
  • des exportations ou dumps non autorisés.

Recherche de compromission avancée

Si une exploitation est suspectée avant patch, il peut être nécessaire de traiter l’instance comme potentiellement compromise :

  • préserver les logs web, PHP-FPM, reverse proxy, WAF et SQL ;
  • réaliser une copie forensique si l’enjeu métier le justifie ;
  • comparer l’arborescence applicative au dépôt Git ou à l’artefact de référence ;
  • vérifier les comptes d’administration Drupal, SFTP, SSH et panel d’hébergement ;
  • faire une rotation des secrets exposés dans settings.php, variables d’environnement, clés API et mots de passe DB si un doute existe.

Dans les environnements mutualisés, il faut aussi vérifier si l’hébergeur a observé des comportements similaires sur d’autres instances. Un attaquant qui cible massivement Drupal sur une plateforme donnée peut laisser des traces transverses côté infrastructure. Chez des acteurs comme OVHcloud, o2switch ou Scaleway, les journaux réseau et les métriques de reverse proxy peuvent aider à identifier une campagne plus large.

Mitigation

Le patch reste la seule réponse fiable. Si une mise à jour immédiate est impossible pour des raisons de compatibilité ou de fenêtre de changement, des mesures temporaires peuvent réduire l’exposition, sans la supprimer totalement.

  • Restreindre l’accès aux interfaces d’administration via ACL, VPN, filtrage IP ou authentification forte en frontal.
  • Activer ou durcir le WAF pour bloquer les motifs d’injection SQL les plus évidents, en gardant à l’esprit qu’un WAF ne remplace pas le correctif.
  • Limiter l’exposition Internet des préproductions, clones et sites dormants.
  • Réduire les privilèges SQL du compte applicatif au strict nécessaire.
  • Renforcer la journalisation HTTP, PHP et SQL sur la période de risque.
  • Surveiller les comptes et les modifications de contenu en temps réel.

Exemples de mesures pratiques :

iptables -A INPUT -p tcp --dport 443 -s IP_AUTORISEE -j ACCEPT

iptables -A INPUT -p tcp --dport 443 -j DROP

Ou côté reverse proxy :

location /admin { allow IP_AUTORISEE; deny all; }

Sur le compte SQL, vérifiez qu’il ne dispose pas de privilèges non requis. Un compte Drupal standard n’a pas besoin de droits d’administration globale de la base. La réduction de privilèges limite l’impact d’une injection même si elle n’empêche pas l’exploitation initiale.

Si une instance ne peut pas être patchée rapidement car elle dépend d’un module non compatible, la bonne décision n’est pas de “vivre avec le risque” sur Internet. Il faut envisager :

  • une isolation réseau temporaire ;
  • une publication restreinte derrière authentification ;
  • un basculement vers une version saine ou un site statique de secours ;
  • une montée de version accélérée du module bloquant ;
  • une désactivation du service si l’exposition n’est pas indispensable.

Cette logique est particulièrement importante pour les environnements publics sensibles : collectivités, établissements de santé, enseignement supérieur, opérateurs de services et médias. Une SQLi activement exploitée sur un CMS exposé est un risque de compromission à court terme, pas un simple écart de conformité.

Sur le plan stratégique, l’épisode rappelle plusieurs bonnes pratiques de fond :

  • maintenir un inventaire vivant des CMS et frameworks exposés ;
  • standardiser les déploiements Drupal avec Composer et des pipelines reproductibles ;
  • imposer des comptes SQL à privilèges minimaux ;
  • réduire le nombre de sites “orphelins” ou sans propriétaire identifié ;
  • intégrer les flux CISA KEV, advisories éditeurs et CERT dans la veille sécurité ;
  • préparer des procédures de patch d’urgence testées à l’avance.

La source originale à retenir pour le suivi technique est l’avis de sécurité Drupal documentant CVE-2025-3169, complété par l’entrée CISA Known Exploited Vulnerabilities qui confirme l’exploitation active et par l’article de BleepingComputer qui a relayé l’obligation de correction imposée aux agences fédérales. Pour les équipes françaises, ce trio d’informations suffit à justifier une accélération immédiate du patch management sur les instances Drupal exposées.

En pratique, la bonne séquence est claire : recenser les sites Drupal publics, identifier les versions vulnérables, appliquer la mise à jour vers 10.3.13, 10.4.3, 11.1.6 ou 11.2.1, puis rechercher des signes d’exploitation avant et après déploiement. Si la dette technique ralentit la correction, il faut compenser par une réduction forte de l’exposition et un contrôle renforcé des journaux. Pour aller plus loin sur le durcissement, la gouvernance de mise à jour et les réflexes opérationnels côté production, un détour par la catégorie /categorie/pratiques reste utile pour transformer cette alerte ponctuelle en amélioration durable de l’hygiène web.

Rubrique Frameworks
Partager
Retour aux actualités