Le 20 mai 2026, l'équipe de sécurité de Drupal a publié l'avis SA-CORE-2026-004, portant la référence CVE-2026-9082. Score attribué : 23 sur 25 sur l'échelle interne de Drupal, soit la mention "Highly critical". Ce score a été révisé deux jours plus tard, le 22 mai. Pour donner un point de comparaison, Drupal n'atteint ce niveau qu'une poignée de fois par décennie.
La vulnérabilité est une injection SQL dans la couche d'abstraction de base de données du cœur de Drupal. Elle ne nécessite aucune authentification. N'importe quel visiteur anonyme peut l'activer si votre infrastructure répond aux critères techniques exposés ci-dessous.
Un attaquant sans le moindre compte sur votre plateforme peut déclencher cette faille. C'est le point de départ qui conditionne tout le reste.
L'impact couvre un spectre large : de la divulgation de données confidentielles jusqu'à, dans certaines configurations, une élévation de privilèges et une exécution de code à distance. Ce n'est pas une extrapolation théorique : l'advisory de drupal.org mentionne explicitement ces trois niveaux de conséquence. L'exécution de code à distance sur un CMS gouvernemental ou bancaire signifie en pratique une prise de contrôle complète du serveur, avec accès aux bases de données clients, aux jetons de session, voire aux systèmes internes connectés.
Côté délai d'exploitation, l'historique parle de lui-même. Comme le souligne Tenable dans son analyse, les vulnérabilités Drupal de cette sévérité ont historiquement été exploitées en heures ou en jours après leur divulgation publique. Un PoC de détection et le différentiel du correctif ont été rendus publics dans les heures qui ont suivi l'annonce du 20 mai. La fenêtre d'action est donc très courte. Comprendre sa propre surface d'attaque est ici une précondition indispensable : ce que recouvre réellement la notion de surface d'attaque pour une organisation mérite d'être clarifié avant même d'aborder la remédiation.
La faille est circonscrite aux installations Drupal fonctionnant sur PostgreSQL. MySQL, MariaDB et SQLite ne sont pas affectés. Pourquoi cette différence ?
Tout se joue dans un fichier précis : core/modules/pgsql/src/EntityQuery/Condition.php. Ce fichier contient une surcharge spécifique à PostgreSQL, conçue pour gérer les comparaisons insensibles à la casse via le chemin EntityQuery. À l'intérieur, une boucle traite les conditions de type IN. Le problème : cette boucle part du principe que le tableau reçu est indexé numériquement. Si l'appelant transmet un tableau associatif, la clé, qui peut être une chaîne arbitraire choisie par l'attaquant, se retrouve directement incorporée dans la requête SQL sans assainissement.
MySQL et SQLite, eux, passent par le chemin standard Connection::expandArguments() de Drupal. Cette fonction génère des noms de paramètres séquentiels à partir d'un compteur interne et ne consulte jamais les clés fournies par l'appelant. Le vecteur vulnérable est donc exclusif à la surcharge PostgreSQL. Comme le détaille l'analyse technique de Searchlight Cyber, le correctif applique simplement array_values() pour forcer les clés à redevenir des entiers séquentiels avant l'émission de la requête, en trois endroits distincts du code, dont une protection en profondeur sur le chemin PostgreSQL.
Deux vecteurs d'attaque ont été documentés par Searchlight Cyber.
Premier vecteur : l'endpoint de connexion JSON. L'URL /user/login?_format=json accepte des corps au format JSON. Lorsqu'un attaquant soumet le champ name non pas comme une chaîne simple, mais comme un objet JSON, Drupal reçoit un tableau associatif. Une seconde clé de cet objet, contenant du SQL embarqué, devient le point d'injection. La technique d'extraction utilisée est dite "blind boolean" : l'attaquant n'obtient pas de résultat direct, mais déduit la valeur cherchée bit par bit en observant les codes HTTP retournés. Concrètement, une division par zéro déclenchée volontairement renvoie HTTP 500 si la condition testée est vraie, HTTP 400 si elle est fausse. En enchaînant ces requêtes, on peut exfiltrer des données de la base sans jamais voir une seule ligne de résultat.
Second vecteur : les filtres JSON:API. Les paramètres de requête de type filter[t][condition][value][`]=x exploitent le mécanisme d'analyse des clés entre crochets. Un seul backtick, guillemet ou caractère invalide dans la clé déforme le nom du paramètre SQL généré et provoque une erreur SQLSTATE[HY093]. Ce vecteur est particulièrement préoccupant pour les sites exposant une API JSON:API publique, ce qui est fréquent dans les architectures découplées type "headless CMS".
Savoir si de telles tentatives ont déjà eu lieu sur votre périmètre implique de disposer des bons indicateurs de compromission. Comprendre ce que sont les indicateurs de compromission et pourquoi ils comptent est un préalable pour détecter ce type d'exploitation silencieuse.
Les versions affectées couvrent une large plage, de Drupal 8 jusqu'aux branches actives :
Les versions corrigées sont : 10.4.10, 10.5.10, 10.6.9, 11.1.10, 11.2.12 et 11.3.10.
Cas particuliers à connaître : Drupal 9.5 et 8.9 disposent de fichiers de correctif disponibles séparément, hors du cycle de mise à jour standard. Drupal 7 n'est pas affecté. Ces branches sont en fin de vie et leur maintien en production constitue un risque distinct, indépendant de CVE-2026-9082.
Condition sine qua non : la faille ne s'active que si le site utilise PostgreSQL comme base de données. Si votre déploiement repose sur MySQL, MariaDB ou SQLite, vous n'êtes pas exposé à cette injection SQL spécifique.
La priorité absolue est de patcher. Appliquez la version corrigée correspondant à votre branche dès que possible, sans attendre votre prochain cycle de maintenance. Si vous êtes sur une version 8.x ou 9.5, récupérez les fichiers de correctif séparément publiés par l'équipe Drupal.
Un point important à ne pas négliger : même si votre site tourne sur MySQL, MariaDB ou SQLite, la mise à jour reste nécessaire. Les versions corrigées embarquent des correctifs coordonnés pour des composants Symfony et Twig, livrés en parallèle de CVE-2026-9082. Ne pas mettre à jour sous prétexte que vous n'utilisez pas PostgreSQL serait une erreur d'appréciation.
Sur le plan de la surveillance, activez la journalisation détaillée des requêtes vers /user/login?_format=json et des paramètres JSON:API contenant des caractères inhabituels dans les clés de filtre. Les erreurs SQLSTATE[HY093] répétées dans vos logs applicatifs sont un signal à investiguer immédiatement. Si vous n'avez pas encore de processus structuré de veille sur les CVE affectant votre stack technique, c'est le moment d'en mettre un en place.
Non, l'injection SQL décrite dans SA-CORE-2026-004 est exclusive aux installations PostgreSQL. Le chemin de code vulnérable n'existe pas dans les drivers MySQL, MariaDB ou SQLite. Cela dit, mettre à jour reste utile pour bénéficier des correctifs Symfony et Twig inclus dans les mêmes versions correctives.
Tenable souligne explicitement ce décalage : le score NVD de 6.5 ne capte pas correctement la sévérité réelle dans les configurations affectées, notamment parce que la faille est exploitable sans aucune authentification. Le score Drupal de 23/25 tient compte du contexte d'exploitation concret, ce qui le rend plus pertinent pour évaluer la priorité de remédiation.
Au moment de la divulgation le 20 mai 2026, aucune exploitation active n'avait été observée. Cependant, un PoC de détection et le diff du correctif sont devenus publics dans les heures suivantes. Les précédents historiques sur des vulnérabilités Drupal de niveau comparable montrent que le délai entre divulgation et exploitation en conditions réelles se compte en heures ou en jours.
Vérifiez le fichier de configuration de la base de données de votre installation, généralement settings.php, dans la section $databases. Si le driver déclaré est pgsql, vous êtes dans le périmètre affecté. Si vous gérez plusieurs instances Drupal dans votre organisation, un inventaire précis de vos bases de données est indispensable avant de conclure à une absence d'exposition.
