Le 20 mai 2026, la Drupal Security Team a publié la faille critique CVE-2026-9082. Si l'injection SQL cible uniquement les infrastructures PostgreSQL, cette mise à jour d'urgence embarque également des correctifs universels pour 13 failles Twig et 35 CVE Symfony.
Pour ceux qui suivent Drupal depuis de nombreuses années, l’annonce du 18 mai 2026 annonçant une faille critique (notée 20/25 sur l’échelle de risque de la team sécurité Drupal) a sonné comme un très mauvais souvenir.
Les trois dernières fois que l’équipe de sécurité avait communiqué de la sorte remontaient alors à 2014 et 2018 pour des failles surnommées les “Armageddon de Drupal”, ou Drupalgeddon. Des failles si critiques que l’on annonçait que quelques heures suffiraient à un attaquant pour les comprendre et coder un exploit à utiliser.
A-t-on vécu un quatrième Drupalgeddon ? L'objet de cet article est simple : poser les faits, préciser le périmètre exact d'impact, et donner aux équipes techniques et aux décideurs les éléments pour agir de façon proportionnée.
Une mise à jour de sécurité qui en cache une autre.
Le premier point sur lequel il est nécessaire d’insister est que lorsque les mises à jour de sécurité de Drupal ont été publiées, elles ne concernaient pas uniquement la faille annoncée le 18 mai. Ces mises à jour emportaient avec elle une seconde mise à jour tout aussi critique : une mise à jour de TWIG corrigeant 13 vulnérabilités dans le moteur de template (donc 2 critiques, 3 hautes).
Revenons donc sur les deux éléments de ces releases.
La faille Drupal SA-CORE-2026-004 : une injection SQL dans l'API d'abstraction DB
La vulnérabilité réside dans l'API d'abstraction de base de données du Core de Drupal. Cette couche, fondamentale dans l'architecture du CMS, a précisément pour mission d'assainir les requêtes envoyées à la base de données pour empêcher les injections SQL.
Un défaut dans le mécanisme de protection permet à un attaquant d'envoyer une requête spécialement forgée qui contourne cette protection et conduit à une injection SQL arbitraire. Deux caractéristiques rendent la faille particulièrement sensible :
- Elle est exploitable de manière anonyme : aucun compte utilisateur n'est requis pour la déclencher ;
- Elle peut conduire à de la divulgation d'informations, et dans certains cas à de l'élévation de privilèges, voire à de l'exécution de code à distance (RCE).
C'est cette combinaison, pas d'authentification requise, impact potentiel jusqu'à la RCE, qui justifie la note de 20/25 attribuée par Drupal, même si le score CVSS officiel publié par CVE.org se situe à 6.5.
Le point clé : seuls les sites PostgreSQL sont exposés à l'injection SQL
C'est l'élément le plus important à retenir, et celui qui est le plus souvent mal interprété dans les relais médiatiques.
La vulnérabilité d'injection SQL n'affecte que les sites Drupal utilisant PostgreSQL comme base de données.
Les sites Drupal qui tournent sur MySQL ou MariaDB ne sont pas exposés à cette injection SQL. Cette spécificité s'explique par des différences dans la façon dont les drivers gèrent le quoting et le typage des paramètres : la faille exploite un comportement propre au driver PostgreSQL de la couche d'abstraction Drupal.
C'est d'ailleurs cette portée restreinte qui a conduit Drupal à classer la cible comme « Uncommon » dans le détail de la note de risque — tout en maintenant la sévérité Highly Critical pour les sites effectivement concernés.
La note de sécurité précise que TOUTES les versions de Drupal depuis la 8.9.0 !
Les versions de Drupal antérieures à la 10.4 ne sont plus couvertes par les patchs de sécurité. Si vous êtes concerné, il est nécessaire de finaliser rapidement des montées de version ou de vous faire accompagner pour les corriger.
Le volet Symfony et Twig : le diable dans le détail
C'est ici qu'il faut faire attention à ne pas tirer de conclusion trop rapide. Si vous êtes sur MySQL, vous pourriez être tenté de conclure que cette release ne vous concerne pas. Ce serait une erreur.
Les releases Drupal pour les branches supportées (11.3, 11.2, 10.6 et 10.5) dans le cadre de mises à jour de sécurité embarquent également des mises à jour de sécurité coordonnées pour Symfony et Twig. Ces deux projets, qui, dans la journée du 20 mai, ont publié une série de messages indiquant la correction de 35 CVE sur Symfony et TWIG. Ces mises à jour ont été publiées quelques heures avant celles de Drupal, en coordination avec les équipes de sécurité.
Ces correctifs Symfony et Twig s'appliquent à tous les sites Drupal, indépendamment de la base de données utilisée.
Selon votre configuration et les modules contribués installés, votre site peut être exposé à une ou plusieurs de ces vulnérabilités upstream. L'équipe sécurité Drupal recommande donc explicitement de mettre à jour, que vous soyez sur PostgreSQL ou non. C'est un message important à faire passer aux DSI et aux équipes ops : la lecture rapide « je suis sur MySQL, je ne suis pas concerné » est partiellement fausse.
Un point de vigilance supplémentaire à signaler : pensez à vérifier quels rôles utilisateurs disposent du droit de modifier des templates Twig (par exemple via Views ou des modules permettant de manipuler des templates). C'est un vecteur secondaire à auditer dans le cadre de ces correctifs.
Versions concernées et plan de remédiation
Versions impactées et correctifs officiels
Les branches supportées suivantes disposent d'un correctif officiel à appliquer immédiatement :
- Drupal 11.3.x — mettre à jour vers la dernière version de patch
- Drupal 11.2.x — mettre à jour vers la dernière version de patch
- Drupal 10.6.x — mettre à jour vers la dernière version de patch
- Drupal 10.5.x — mettre à jour vers la dernière version de patch
Correctifs « best effort » pour les branches EOL
Compte tenu de la sévérité, l'équipe Drupal a fait l'effort exceptionnel de publier des correctifs best effort pour des branches officiellement en fin de vie :
- Drupal 11.1.x
- Drupal 10.4.x
- Drupal 9.5.x
- Drupal 8.9.x
Si vous êtes sur l'une de ces branches, c'est l'occasion d'appliquer le patch d'urgence, et surtout, c'est un signal fort qu'une trajectoire de migration vers une branche supportée devient prioritaire.
Drupal 7 : non concerné
Drupal 7 n'est pas affecté par cette vulnérabilité. Aucune action n'est requise au titre de la CVE-2026-9082 sur ces sites. Cela ne change évidemment rien à la nécessité globale de planifier une migration de Drupal 7, qui n'est plus en support communautaire depuis janvier 2025.
Checklist d'action immédiate
- Identifier votre stack : quelle base de données ? Quelle version de Drupal ? Quels modules contribués manipulant des templates Twig ?
- Appliquer le patch core correspondant à votre branche.
- Auditer les rôles disposant des permissions de modification de templates Twig ou d'édition de Views.
- Vérifier les logs d'accès récents à la recherche de requêtes anormales, la fenêtre entre annonce et patch a été courte mais réelle.
- Re-tester vos environnements de préproduction avant déploiement.
Un mot sur la gestion de l'incident par la communauté Drupal
Au-delà du correctif lui-même, il y a une chose qui mérite d'être soulignée : la qualité du processus. L'équipe sécurité Drupal a :
- Publié un Public Service Announcement deux jours en amont pour permettre aux équipes ops de bloquer un créneau de déploiement ;
- Annoncé une fenêtre de release précise (17h00–21h00 UTC le 20 mai) ;
- Coordonné la divulgation avec Symfony et Twig pour éviter une publication désynchronisée des advisories upstream ;
- Etendu les correctifs à des branches officiellement EOL, en best effort.
C'est exactement ce qu'on attend d'un projet open source mature, et c'est aussi pour ça qu'on continue, chez Smile, à recommander et accompagner Drupal sur des projets sensibles : la robustesse n'est pas seulement dans le code, elle est aussi dans le processus de réponse aux incidents.
En synthèse
- La faille est réelle et sévère, mais son périmètre d'injection SQL est limité aux sites PostgreSQL.
- Les mises à jour Symfony et Twig embarquées concernent tous les sites Drupal, quelle que soit la base de données.
- Les branches EOL bénéficient d'un correctif best effort, saisissez l'occasion pour planifier la migration.
- L'écosystème Drupal a, une fois de plus, démontré la qualité de sa gestion de sécurité.
Si vous souhaitez un audit d'exposition sur votre site Drupal, valider votre plan de remédiation, ou échanger sur une stratégie de migration depuis une branche EOL, mon équipe et moi sommes à votre disposition. Vous pouvez nous contacter directement via notre formulaire de contact.
