Qu'est-ce que la PSA-2026-05-18 et l'advisory SA-CORE-2026-004 ?

Le 18 mai 2026, la Drupal Security Team a diffusé une Public Service Announcement (PSA-2026-05-18) pour prévenir, deux jours à l'avance, qu'un correctif majeur arrivait. L'advisory correspondante, SA-CORE-2026-004, est ensuite parue le 20 mai 2026 dans la fenêtre 17h-21h UTC. Elle ferme une injection SQL (CVE-2026-9082) logée dans la brique Database abstraction API du noyau Drupal, qui ne frappe que les installations adossées à PostgreSQL. Drupal lui attribue 20/25 sur sa propre échelle (Highly Critical) et la juge exploitable sans aucun compte. Aucune alerte de cette intensité n'avait été émise depuis Drupalgeddon 2, en mars 2018.

Quelles versions de Drupal sont affectées et corrigées ?

L'ensemble des branches 8.x, 9.x, 10.x et 11.x porte la faille. Les correctifs officiels sont 11.3.10 (branche 11.3), 11.2.12 (branche 11.2), 11.1.10 (branche 11.1 en fin de vie, livré en best-effort), 10.6.9 (branche 10.6), 10.5.10 (branche 10.5) et 10.4.10 (branche 10.4 en fin de vie, best-effort). Pour les branches 8.x et 9.x déjà retirées du support communautaire, Drupal a publié à titre exceptionnel les patches fichiers 8.9.20 et 9.5.11, tout en répétant qu'il vaut mieux basculer sur une branche encore maintenue. Drupal 7, lui, échappe complètement à cette vulnérabilité.

Mon site est sous MySQL / MariaDB, suis-je concerné ?

L'injection SQL proprement dite (CVE-2026-9082) ne touche que PostgreSQL ; MySQL, MariaDB et SQLite restent hors d'atteinte par ce vecteur. Mais la livraison Drupal du 20 mai 2026 ne se résume pas à cela : elle intègre aussi des correctifs critiques sur des dépendances tierces, à savoir Twig 3.26.0 (13 CVE, dont des injections de code PHP), Symfony 6.4.40 et 7.4.12 (10 CVE, notamment de l'URL injection et un contournement d'HtmlSanitizer), Composer 2.9.8 et Underscore.js 1.13.8. Ces corrections valent pour n'importe quel moteur de base. Conclusion : peu importe le SGBD, tout site en production gagne à être patché sous 72 heures.

Comment patcher si mon site est sous Drupal 8.4 ou une version 8.x ancienne ?

Côté Drupal 8, seul le correctif de la branche 8.9 est diffusé. Si votre site tourne sur une 8.0 à 8.8, deux chemins s'offrent à vous : d'abord remonter jusqu'à 8.9.20 avant d'y poser le patch officiel (comptez 2 à 4 jours, le temps de franchir cinq versions mineures), ou bien retravailler à la main le patch pour qu'il colle à votre 8.x actuelle (0,5 à 1 jour). Drupal prévient lui-même que cette adaptation manuelle est « not guaranteed to work correctly, might introduce other bugs or regressions ». À mes yeux, le choix le plus sain reste de migrer vers une branche soutenue comme Drupal 11.3, d'autant que Drupal 8 n'est plus maintenu par la communauté depuis novembre 2021.

Quels sont les prérequis PHP et base de données pour les versions corrigées ?

Pour 11.3 et 11.2, il faut au moins PHP 8.3, avec MySQL 8.0, MariaDB 10.6, PostgreSQL 16 et SQLite 3.45. Pour 10.6 et 10.5, le plancher est PHP 8.1 (8.3 ou plus conseillé) accompagné de MySQL 5.7.8, MariaDB 10.3.7, PostgreSQL 12 et SQLite 3.26. La 10.4 en fin de vie réclame PHP 8.1 au minimum, la 9.5 PHP 7.4, et la 8.9 PHP 7.0.8 (7.3 et au-delà étant recommandés). Avant d'engager un patch ou une migration, je vérifie systématiquement la version de PHP et celle de la base chez l'hébergeur : si l'environnement bloque, tout le calendrier glisse.

Quel est le risque réel pour mon site ?

Selon l'advisory, n'importe quel visiteur non identifié peut tenter l'attaque par une simple requête HTTP forgée, sans réglage spécial dès lors que la base est en PostgreSQL. Au 21 mai 2026, aucune exploitation observée publiquement n'avait été rapportée, mais le danger se concentre sur les heures et jours qui suivent la divulgation : c'est le laps de temps habituel avant l'apparition d'un proof-of-concept et de scans automatisés en masse. Rappelez-vous que Drupalgeddon 2, en mars 2018, avait fait tomber plus d'un million de sites Drupal en l'espace de quelques heures. La PSA le dit sans détour : « exploits might be developed within hours or days ».

Mon site Drupal 7 est-il concerné ?

Drupal 7 n'est PAS affecté par SA-CORE-2026-004. Cela ne change rien à la situation de fond : Drupal 7 est en fin de vie communautaire depuis le 5 janvier 2025, plus aucun correctif de sécurité n'est publié sur cette branche. Un site Drupal 7 en production est exposé à toutes les failles découvertes depuis cette date, sans patch. Voir mon guide fin de vie Drupal 7 pour les options de migration ou de support étendu HeroDevs.

Drupal Steward me protège-t-il ?

Drupal Steward est un service de reverse-proxy WAF géré par la Drupal Association, utilisant le ruleset OWASP mod_security plus des règles spécifiques Drupal. Pour les sites abonnés à Steward, une défense automatique contre les vecteurs d'attaque connus de SA-CORE-2026-004 est en place. Cela ne dispense PAS de patcher : Steward est une mitigation temporaire, pas un substitut. Le patch doit être appliqué dès que possible.

Combien coûte un audit avant patch ou migration ?

Un audit pré-patch standard chez ReydenWeb se chiffre à 1 jour de travail expert. Le livrable : un mini-rapport avec inventaire des versions (PHP, MySQL/PostgreSQL, OS, hébergeur), inventaire des modules contribués et de leur statut, des patches déjà appliqués via composer-patches, du code custom et de sa compatibilité, recommandations concrètes et chiffrage de la migration ou du patch. Cet audit est la porte d'entrée à toute intervention sur un site Drupal hors TMA. Pour les sites en TMA active, l'audit est intégré au forfait annuel.

SA-CORE-2026-004 Drupal : quel patch par version ?

Par Driss Redouane · Publié le 21 mai 2026 · 14 min de lecture

Faille Highly Critical, cotée 20/25 - Ce mercredi 20 mai 2026, la Drupal Security Team a mis en ligne l'advisory SA-CORE-2026-004 (CVE-2026-9082), dont la PSA-2026-05-18 avait prévenu deux jours auparavant. En cause : une injection SQL nichée dans la couche Database abstraction API du noyau, qu'un visiteur anonyme peut déclencher dès lors que le site repose sur PostgreSQL. Aucune annonce Drupal d'une telle gravité n'avait circulé depuis Drupalgeddon 2, en mars 2018.

Je reprends ici, sans dramatiser, le déroulé des faits, le périmètre exact des correctifs, la marche à suivre suivant la branche Drupal que vous exploitez, et les seuils PHP comme base de données à anticiper. Ce contenu vise les directions des systèmes d'information, responsables techniques et développeurs qui doivent trancher vite sur un ou plusieurs sites Drupal en ligne. J'actualise la page chaque fois qu'une nouvelle information officielle est publiée.

L'essentiel en soixante secondes

Nature du défaut : injection SQL logée dans la couche Database abstraction API, et seuls les sites PostgreSQL y sont vulnérables.
Cotation : 20/25 sur l'échelle Drupal Risk (Highly Critical), exploitable sans compte et avec une barrière d'accès très basse.
Branches corrigées : 11.3.10, 11.2.12, 10.6.9, 10.5.10, plus des patches best-effort pour 11.1.10, 10.4.10, 9.5.11 et 8.9.20.
Dépendances rafraîchies au passage : Twig 3.26.0, Symfony 6.4.40 / 7.4.12, Composer 2.9.8, Underscore.js 1.13.8 — ce qui touche l'intégralité des installations Drupal, peu importe le moteur de base.
Drupal 7 hors du champ de cette faille, mais en fin de vie depuis le 5 janvier 2025, donc exposé à toutes les autres vulnérabilités sans correctif.

Anatomie de la vulnérabilité

Le défaut porte l'identifiant CVE-2026-9082 et relève de la classe CWE-89 (« Improper Neutralization of Special Elements used in an SQL Command »). Il loge dans la brique Database abstraction API du noyau, c'est-à-dire la couche par laquelle transitent toutes les requêtes SQL produites par les modules du cœur comme par les modules contribués.

Ce que dit la fiche officielle

Catégorie : injection SQL (CWE-89)
Brique concernée : Database abstraction API du cœur Drupal
Moteur exposé : PostgreSQL exclusivement — MySQL, MariaDB et SQLite échappent à ce vecteur
Note Drupal Risk : 20/25, soit le palier Highly Critical
Détail du calcul : Access complexity = None, Authentication = None, Confidentiality impact = All non-public data, Integrity impact = All data modifiable
Note CVSS 3.1 NVD : 6.5 (Medium). L'écart avec le 20/25 de Drupal vient de son barème maison, qui sanctionne bien plus lourdement l'absence d'authentification.
Mode d'attaque : une simple requête HTTP forgée, sans compte ni réglage préalable
Exploitation constatée au 21 mai 2026 : rien de public pour l'instant, mais la fenêtre la plus dangereuse couvre les jours qui suivent la divulgation

Pourquoi PostgreSQL et lui seul

Si Drupal mutualise une couche d'abstraction commune pour générer ses requêtes, chaque driver applique en réalité sa propre mécanique d'échappement et de préparation. Le problème naît d'un cas de figure précis : une séquence d'encodage que MySQL et SQLite désamorcent d'office, mais que PostgreSQL laisse passer. Sous les autres moteurs, le code fautif est bien présent, simplement il n'est pas activable par ce chemin. Tout site Drupal en production adossé à PostgreSQL passe donc en tête de liste des urgences.

D'où vient cette gravité

Le score de 20/25 résulte de trois ingrédients cumulés. Un : aucune authentification n'est requise, si bien que n'importe quel inconnu peut tenter sa chance depuis le web sans même s'inscrire. Deux : la barrière d'entrée est dérisoire — ni configuration particulière, ni privilège, ni enchaînement d'exploits sophistiqué. Trois : une injection SQL ouvre, en théorie, la lecture de l'ensemble des données non publiques (comptes, contenus protégés, configuration), leur altération (fabrication d'un administrateur, prise de contrôle), voire un rebond vers de l'exécution de code distant selon la base. La PSA le dit noir sur blanc : « exploits might be developed within hours or days ».

Au-delà de PostgreSQL : Twig, Symfony et Composer dans le lot

La livraison du 20 mai 2026 ne s'arrête pas au correctif d'injection SQL. Drupal en a profité pour embarquer une série de mises à niveau de composants tiers, plusieurs étant elles-mêmes classées critiques. Un site sous MySQL ou MariaDB n'est certes pas atteint par la SQLi PostgreSQL, mais il hérite des CVE de ces dépendances : il a donc lui aussi besoin du correctif.

Twig 3.26.0 (20 mai 2026)

Contournement de sandbox par __toString : injection de code PHP critique sur les environnements multi-tenant
XSS dans HtmlDumper, sur les sorties de débogage
Filtres de sortie HTML marqués à tort is_safe (twig/extras)
Échappement HTML contournable via le filtre spaceless
Mémoïsation non bornée dans intl-extra, exploitable en déni de service
Au total 13 advisories sorties d'un seul bloc sur GitHub, dont 2 critiques. Source : github.com/twigphp/Twig/security/advisories

Symfony 6.4.40 et 7.4.12 (20 mai 2026)

10 CVE divulguées le même jour : CVE-2026-45063, 45064, 45065, 45066, 45070, 45754, 45755, 45756, 46626 et 47212
Au menu : injection d'URL, contournement d'HtmlSanitizer et divers défauts dans HttpFoundation et Validator
Le cœur de Drupal subit « some of these vulnerabilities », pour reprendre la formule officielle
Source : symfony.com/blog/category/security-advisories

Les autres briques remises à niveau

Composer 2.9.8 : durcissement sécurité, à surveiller sur les pipelines CI/CD qui lancent composer install au déploiement
Underscore.js 1.13.8 : durcissement côté front, réservé à Drupal 10.6.9

Ce qu'il faut en retenir : se dire « on tourne sur MySQL, donc rien à craindre » est une erreur. L'injection SQL PostgreSQL fait le titre de l'advisory, mais les CVE Twig et Symfony qui l'accompagnent visent l'ensemble du parc Drupal. Le correctif s'applique partout, quel que soit le moteur de base, dans la fenêtre de 72 heures préconisée par Drupal.

Branches touchées et branches déjà corrigées

La faille frappe toutes les branches 8.x, 9.x, 10.x et 11.x ; seul Drupal 7 reste à l'écart de ce défaut précis. Le tableau qui suit récapitule les correctifs officiellement mis en ligne le 20 mai 2026.

Branche	Statut	Version vulnérable	Version corrigée	Type de patch
Drupal 11.3	Supportée	< 11.3.10	11.3.10	Composer direct
Drupal 11.2	Supportée (EOL juin 2026)	< 11.2.12	11.2.12	Composer direct
Drupal 11.1 / 11.0	EOL	toutes	11.1.10 (patch fichier)	Best-effort, migration recommandée
Drupal 10.6	Supportée	< 10.6.9	10.6.9	Composer direct
Drupal 10.5	Supportée (LTS jusqu'à juin 2026)	< 10.5.10	10.5.10	Composer direct
Drupal 10.4	EOL	toutes	10.4.10 (patch fichier)	Best-effort, migration recommandée
Drupal 10.3 et antérieures 10.x	EOL	toutes	Aucun patch direct	Upgrade vers 10.5 ou 10.6 puis patch
Drupal 9.5	EOL nov. 2023	toutes	9.5.11 (patch fichier)	Best-effort, migration recommandée
Drupal 9.0 - 9.4	EOL	toutes	Aucun patch direct	Migrer en 9.5.11 ou directement Drupal 11.3
Drupal 8.9	EOL nov. 2021	toutes	8.9.20 (patch fichier)	Best-effort, migration recommandée
Drupal 8.0 - 8.8	EOL	toutes	Aucun patch direct	Migrer en 8.9.20 puis patch, ou direct Drupal 11
Drupal 7	EOL janv. 2025	Non concerné	-	Autres failles non corrigées depuis l'EOL

Ces correctifs « best-effort » destinés aux branches en fin de vie (11.1, 10.4, 9.5, 8.9) relèvent d'une dérogation que Drupal n'accorde qu'en raison de la criticité. Le projet ne s'en cache pas : « provided as one-time best-effort, not guaranteed to work correctly, might introduce other bugs or regressions ». Pour 11.0, les 10.3 et plus anciennes, les 9.0 à 9.4 et les 8.0 à 8.8, aucun correctif applicable directement n'existe : la marche à suivre est d'abord de monter sur la dernière mineure de la branche, puis de poser le patch.

Quel parcours de correction selon votre branche

Voici les scénarios pratiques, du plus direct — vous êtes déjà sur la dernière mineure soutenue — au plus délicat, lorsqu'il faut franchir plusieurs versions abandonnées d'affilée.

Vous tournez en Drupal 11.3.x

La situation la plus confortable. Lancez composer require drupal/core-recommended:11.3.10 drupal/core-composer-scaffold:11.3.10 drupal/core-project-message:11.3.10 --update-with-dependencies, enchaînez avec drush updb puis drush cr, et validez en préproduction. Comptez en général 2 à 4 heures, tests compris, sans crainte de régression notable.

Vous tournez en Drupal 11.2.x

Montée directe vers 11.2.12 via la même commande Composer, ajustée à la version. Comme 11.2 s'éteint en juin 2026, il faudra de toute façon rejoindre 11.3 avant cette échéance ; cela dit, le correctif immédiat suffit déjà à neutraliser SA-CORE-2026-004.

Vous tournez en Drupal 11.0 ou 11.1 (fin de vie)

Deux voies se présentent. Le choix conseillé : passer d'un coup en 11.3.10 par Composer (en réglant les conflits de dépendances et en testant), ce qui solde au passage les mineures sautées. La parade d'urgence : poser le patch fichier 11.1.10 livré en best-effort pour grappiller 24 heures, puis caler la bascule vers 11.3 dans la semaine. Quoi qu'il arrive, ne campez pas sur 11.0 ou 11.1 au-delà de ce dépannage.

Vous tournez en Drupal 10.6.x

Montée directe vers 10.6.9. La branche 10.6 bénéficie d'un support sécurité jusqu'à l'arrivée de Drupal 12 (décembre 2026). Reste ensuite à arbitrer : migrer vers 11.3 ou patienter jusqu'à Drupal 12, selon votre feuille de route. Voir mon guide Drupal 12 roadmap 2026.

Vous tournez en Drupal 10.5.x (LTS)

Montée directe vers 10.5.10. La 10.5 joue le rôle de version quasi-LTS de la branche 10 et reçoit des correctifs de sécurité jusqu'en juin 2026. À planifier après coup : la transition vers 10.6, vers 11.3, ou l'attente de Drupal 12. Pour les dates et le détail des options, consultez mon guide fin de vie Drupal 10.

Vous tournez en Drupal 10.4 (fin de vie)

Voie conseillée : passer directement en 10.6.9 avec Composer. Voie d'urgence : le patch fichier 10.4.10 fourni en best-effort. Depuis la sortie de 10.5 et 10.6, la 10.4 ne reçoit plus rien et empile les failles non corrigées. La montée vers 10.6 — ou directement vers 11.3 — doit suivre sans tarder.

Vous tournez en Drupal 10.0, 10.1, 10.2 ou 10.3 (fin de vie)

Pas de correctif applicable tel quel. Il faut d'abord rejoindre la 10.5 ou la 10.6 (Composer puis tests), avant d'y appliquer le patch de la version visée. Comptez un chantier de 2 à 5 jours selon l'état du code custom et des modules contribués. Sauter directement en 11.3 se défend aussi, si vous voulez éviter une double migration sous six mois.

Vous tournez en Drupal 9.x (fin de vie nov. 2023)

Drupal 9 n'est plus maintenu par la communauté depuis le 1^er novembre 2023. Le patch 9.5.11 arrive en best-effort one-time, mais le constat reste le même : hors exception comme aujourd'hui, plus aucun correctif n'a été publié sur Drupal 9 depuis dix-huit mois. La cible logique est Drupal 11.3, devenue de fait la prochaine LTS pour qui quitte D9. Le degré de difficulté tient à la qualité du code de départ : un site tenu à jour jusqu'en 9.5.x se migre bien plus aisément qu'un 9.0 figé.

Vous tournez en Drupal 8.x (fin de vie nov. 2021)

Profil classique que je croise encore : un site en 8.4.8 toujours en ligne, jamais touché depuis 2017. Drupal 8 a quitté le support communautaire en novembre 2021, soit plus de quatre ans sans correctifs réguliers. Le patch 8.9.20 en best-effort exige d'abord d'être sur la branche 8.9. Pour un site en 8.0 à 8.8, trois pistes :

Piste 1 — remontée 8.x → 8.9.20 puis patch officiel : 2 à 4 jours selon le code, le temps de franchir plusieurs mineures (prérequis PHP, configuration management, modules contribués). C'est la voie homologuée, avec un patch garanti.
Piste 2 — adaptation manuelle du patch à votre 8.x : 0,5 à 1 jour. Tolérée par Drupal, mais étiquetée « not guaranteed to work correctly ». Un pansement provisoire qui ne règle pas le fond.
Piste 3 — migration franche vers Drupal 11.3 : chantier plus conséquent (audit des modules, refactor éventuel), mais qui met le site tranquille pour quatre ans. C'est souvent le meilleur rapport coût/bénéfice en 8.x.

Vous tournez en Drupal 7 (fin de vie janv. 2025)

À la fois rassurant et préoccupant. Le bon côté : SA-CORE-2026-004 ne vous touche pas, l'architecture de Drupal 7 n'ayant rien à voir avec la couche DB abstraction de Drupal 8 et au-delà. Le mauvais : Drupal 7 est sorti du support communautaire le 5 janvier 2025, et plus aucun correctif n'est diffusé depuis. Vous cumulez seize mois de failles laissées ouvertes. Trois options : migrer vers Drupal 11.3 (mon conseil), basculer sur WordPress si Drupal ne se justifie plus, ou souscrire le support étendu payant de HeroDevs. Voir mon guide fin de vie Drupal 7.

Seuils PHP et base de données, branche par branche

Avant tout patch ou toute migration, assurez-vous que la version de PHP et le moteur de base disponibles chez votre hébergeur supportent la version visée. C'est le verrou à lever en premier : si l'hébergement coince, tout le calendrier glisse. Le tableau ci-dessous rassemble les prérequis officiels, recoupés sur drupal.org et les release notes de chaque version. Pour les branches anciennes (8.0 à 8.8), une partie des chiffres vient de la documentation officielle archivée.

Version Drupal	Sortie	PHP min	PHP reco	MySQL min	MariaDB min	PostgreSQL min	SQLite min
8.0	nov. 2015	5.5.9	5.6 / 7.0	5.5.3	5.5.20	9.1.2	3.6.8
8.4	oct. 2017	5.5.9	7.0+	5.5.3	5.5.20	9.1.2	3.6.8
8.7	mai 2019	7.0.8	7.2	5.5.3	5.5.20	9.1.2	3.6.8
8.8	déc. 2019	7.0.8	7.3	5.7.8	10.1	10	3.26
8.9 (LTS)	juin 2020	7.0.8	7.3 / 7.4	5.7.8	10.3.7	10	3.26
9.0	juin 2020	7.3	7.4	5.7.8	10.3.7	10 + pg_trgm	3.26
9.4	juin 2022	7.4	8.1	5.7.8	10.3.7	10	3.26
9.5	déc. 2022	7.4	8.1.6	5.7.8	10.3.7	10	3.26
10.0	déc. 2022	8.1	8.1.6	5.7.8	10.3.7	12 + pg_trgm	3.26
10.5 (LTS)	juin 2025	8.1	8.3	5.7.8	10.3.7	12	3.26
10.6	déc. 2025	8.1	8.4	5.7.8	10.3.7	12	3.26
11.0	août 2024	8.3	8.3	8.0	10.6	16	3.45
11.3	déc. 2025	8.3	8.4	8.0	10.6	16	3.45
12.0 (prévu)	déc. 2026	8.5	8.5	8.0	10.11	18	3.45

Les paliers de transition à garder en tête

PHP 5.5.9 → 7.0.8 : relevé dès Drupal 8.7.0 (mai 2019) pour les installations neuves, puis rendu bloquant en mise à jour à partir de 8.8.0 (décembre 2019).
PHP 7.3 → 7.4 : à partir de Drupal 9.4 (juin 2022), un avertissement apparaît sous 7.3, la sécurité n'étant plus assurée en deçà de 7.4.
PHP 8.1 plancher : posé avec Drupal 10.0 (déc. 2022) ; la 8.1.6 est conseillée pour contourner un bug OPcache des toutes premières 8.1.x.
PHP 8.3 plancher : instauré par Drupal 11.0 (août 2024), avec PHP 8.4 recommandé dès 10.6 et 11.3.
PHP 8.5 plancher : prévu pour Drupal 12.0 (déc. 2026), avec compilation argon2 obligatoire.
Symfony : 3.4 dès Drupal 8.4, 4.4 avec Drupal 9, 6.2 avec Drupal 10.0, 7.1 avec Drupal 11.0, et une branche 8.x annoncée pour Drupal 12.
Côté bases : le palier MySQL 5.7.8 / MariaDB 10.3.7 / PostgreSQL 10 / SQLite 3.26 est entré en vigueur avec Drupal 8.8 et 9.0 ; Drupal 10.0 a relevé PostgreSQL à 12 ; Drupal 11.0 a poussé MySQL à 8, MariaDB à 10.6, PostgreSQL à 16 et SQLite à 3.45.

Une réalité de terrain en mai 2026 : tous les mutualisés n'offrent pas encore PHP 8.4 par défaut, et certaines formules d'entrée de gamme plafonnent à 8.2 ou 8.3. Chez des hébergeurs comme OVH, 1and1, Gandi ou Infomaniak, il faut souvent forcer la bonne version de PHP à la main depuis le panneau d'administration. Cette vérification se fait en amont du plan de migration applicatif, jamais en cours de route.

Sites en retard : la dette de sécurité qui s'empile

SA-CORE-2026-004 ne tombe pas du ciel. Pour un site laissé sans correctif depuis sa fin de vie, le cumul des failles déjà ouvertes pèse parfois plus lourd que la PSA du jour. Quelques repères historiques pour situer l'enjeu :

Drupalgeddon 2 — mars 2018 (SA-CORE-2018-002)

CVE-2018-7600, notée 24/25 (Highly Critical). Une exécution de code distant dans le Form API, déclenchable par requête anonyme. Le proof-of-concept a circulé moins de 48 heures après la divulgation. Plus d'un million de sites Drupal sont tombés dans les semaines qui ont suivi, surtout pour du minage de cryptomonnaie et du défacement. C'est l'antécédent direct de SA-CORE-2026-004.

Drupalgeddon 3 — avril 2018 (SA-CORE-2018-004)

CVE-2018-7602, notée 20/25 (Highly Critical). Une RCE jumelle dans le Form API, cette fois exploitable par un utilisateur déjà connecté. Diffusée trois semaines après Drupalgeddon 2 pour colmater un chemin d'attaque resté ouvert.

SA-CORE-2019-003 et les années qui suivent

Entre 2019 et 2023, plusieurs advisories Highly Critical (RCE, XSS persistant, contournement d'accès) cotées 18 à 19/25, mais sans PSA dédiée. Un site Drupal 8 figé depuis 2018, ou un Drupal 9 jamais touché depuis 2022, traîne ainsi une dizaine de failles documentées — sans même compter celles de ses modules contribués.

SA-CORE-2026-001, 002 et 003

Trois advisories Drupal parues au premier trimestre 2026 sur des vecteurs plus ordinaires (XSS, contournement d'accès). Criticité moyenne à élevée, déjà intégrée aux mineures de mars et avril 2026. Un site à jour de ses mineures est donc couvert sur ces points.

L'enseignement qui traverse tout cela : la maintenance Drupal n'est pas une dépense facultative. Un site sous TMA active reçoit ses correctifs dans les 24 à 72 heures suivant la divulgation. Un site qui en est dépourvu accumule les failles par défaut, et la facture de remise à niveau grimpe d'autant plus vite que le retard s'allonge. Sur les audits que je mène, un Drupal 8.x ou 9.x oublié pendant trois à cinq ans demande couramment 5 à 15 jours de travail expert pour être rattrapé, hors mise en place d'une TMA récurrente.

Ma méthode d'audit avant patch ou migration

Voici la trame que je déroule sur les interventions en urgence après une PSA, ou plus largement pour cadrer une montée de version Drupal. À la clé, un mini-rapport livré sous 24 à 48 heures, chiffrage à l'appui et plan d'action concret.

Relevé de l'infrastructure : version exacte de PHP, version et type de base (PostgreSQL en priorité), version de l'OS, nature de l'hébergement (mutualisé, VPS, cloud), accès SSH ou non, et présence — ou création à prévoir — d'une préproduction iso-prod.
Version précise du cœur Drupal : un drush core:status donne le numéro exact (entre une 8.4.0 et une 8.4.8 d'un même environnement, l'écart compte parfois beaucoup).
Recensement des modules contribués : drush pm:list --status=enabled --type=module --no-core, recoupé avec la liste des projets abandonnés sur drupal.org. Un module sans release récente ou estampillé « abandoned » est une bombe à retardement.
Examen du code custom : modules maison dans modules/custom/, thèmes spécifiques, fichiers settings.php et services.yml, vieux hooks (hook_menu et consorts) qui trahissent du code hérité.
Patches déjà en place : composer-patches.json ou la section patches du composer.json. Pour chacun : toujours utile (issue ouverte sur drupal.org), intégré en amont (donc retirable) ou périmé ?
Chaîne de déploiement : Git en place, intégration continue configurée (GitLab, GitHub Actions, Jenkins, Bitbucket Pipelines), procédure de mise en ligne documentée, retour arrière automatisable ?
Sauvegardes : existe-t-il une politique de backup, à quelle fréquence, avec une restauration testée récemment ? Sans sauvegarde éprouvée, toute intervention de sécurité devient hasardeuse.
Trafic et surface d'exposition : volume quotidien moyen, comptes authentifiés, formulaires ouverts au public, CDN ou pare-feu applicatif en place (Cloudflare, Akamai, Drupal Steward) ?
Données sensibles : y a-t-il des données personnelles, de santé ou financières ? Le périmètre RGPD conditionne le délai légal de notification à la CNIL en cas de compromission (72 heures pour les données personnelles).
Plan d'action : une recommandation motivée (patch immédiat, montée mineure, montée majeure ou refonte), un chiffrage en jours-homme, un calendrier prévisionnel et des jalons de validation côté client.

Sur les interventions urgentes qui suivent une PSA, mon audit pré-patch type tient en 1 jour de travail. Le livrable habituel : un mini-rapport de 4 à 6 pages reprenant les points ci-dessus, assorti de la recommandation chiffrée. Pour les clients en TMA Drupal active, cet audit fait partie du forfait : rien de plus à facturer, et l'intervention démarre sans délai.

Recommandations stratégiques

La bonne décision selon votre profil

Une fois le correctif posé, voici l'orientation que je conseille en fonction de l'état de votre site. Ces repères découlent des projets Drupal que je conduis en France et au Luxembourg, dont un portail national d'information publique de l'État pour le secteur public.

Branche soutenue et à jour — serein

Vous êtes en 11.3, 11.2, 10.6 ou 10.5 avec une TMA active. Vous appliquez le correctif en 2 à 4 heures, vous validez en préproduction, vous mettez en ligne : le déroulé normal d'une TMA sérieuse. Sans contrat de maintenance, c'est le bon moment pour en ouvrir un — un événement de l'ampleur de SA-CORE-2026-004 ne devrait pas reposer sur une décision prise au coup par coup.

Fin de vie récente (10.4, 11.1) — rattrapage express

Vous êtes en 10.4 ou 11.1, tout juste sorties du support. Posez le patch best-effort en urgence, puis rejoignez la dernière version soutenue de la branche dans la semaine. Le retard reste contenu et la remise à niveau est balisée : 2 à 5 jours selon le code custom et les modules contribués.

Drupal 9 — migration à prioriser

Drupal 9 n'est plus maintenu depuis novembre 2023 : dix-huit mois de failles sans correctif se sont accumulés. Visez directement Drupal 11.3, sans crochet par D10 qui s'éteindra en décembre 2026. Chantier courant de 5 à 15 jours selon le code. La PSA du jour est l'occasion idéale de lancer ce projet.

Drupal 8 — urgence puis migration

Drupal 8 est hors support depuis quatre ans et demi. Procédez en deux temps : un correctif d'urgence (best-effort 8.9.20, ou adaptation manuelle si le site est sous 8.9) pour s'offrir un ou deux mois, puis le saut vers Drupal 11.3. Aller droit en D11, sans transiter par D9 ou D10, offre souvent le meilleur retour sur investissement.

Drupal 7 — épargné mais à risque

SA-CORE-2026-004 ne vous touche pas, mais Drupal 7 est hors support depuis janvier 2025, soit seize mois d'autres failles laissées ouvertes. La PSA du jour sert d'alerte : le danger est structurel, pas passager. Vos options : migrer vers Drupal 11, basculer sur WordPress si Drupal ne se justifie plus, ou prendre le support étendu payant de HeroDevs pour gagner du temps. Voir mon guide fin de vie Drupal 7.

Vous ignorez où vous en êtes

Scénario courant : un site Drupal récupéré d'un ancien prestataire, sans inventaire à jour ni chaîne de déploiement documentée. L'audit pré-patch — 1 jour, cadré, avec mini-rapport à la clé — est taillé pour ce cas de figure. Il vous offre une vision nette avant d'arbitrer, et le chiffrage de l'intervention à prévoir.

Et du côté du Luxembourg ?

La PSA vaut pour tout l'écosystème Drupal, quelle que soit la juridiction. Les organisations luxembourgeoises sous Drupal sont donc logées à la même enseigne, avec deux spécificités locales à anticiper.

Notifier la CNPD en cas de compromission

Si l'attaque aboutit et entraîne une fuite de données personnelles, il faut saisir la CNPD (Commission nationale pour la protection des données) dans un délai de 72 heures. Le cadre épouse le RGPD européen, donc l'équivalent de la CNIL en France, mais pour un responsable de traitement établi au Luxembourg, c'est bien la CNPD qui fait référence. La déclaration passe par le portail guichet.lu.

NIS2 et activités critiques

Pour les entités qualifiées d'essentielles ou d'importantes au titre de la directive NIS2 transposée au Luxembourg (loi du 7 décembre 2023), traiter une faille Highly Critical relève des incidents de cybersécurité à déclarer. La HCPN (Haut-Commissariat à la Protection nationale) pilote ces notifications. Un site Drupal compromis qui sert un service essentiel doit être signalé au CSIRT national selon les échéances NIS2 : 24 heures pour l'alerte précoce, 72 heures pour la notification d'incident et un mois pour le rapport final.

La CSSF pour la place financière

Les entités supervisées par la CSSF (Commission de surveillance du secteur financier) suivent un régime propre de signalement des incidents informatiques (circulaire CSSF 22/806, et règlement DORA pour les acteurs financiers européens depuis janvier 2025). Pour le site Drupal exposé d'une banque, d'un assureur ou d'un PSF luxembourgeois, le circuit d'alerte conjugue la CNPD (volet données personnelles), la CSSF (volet régulé) et, le cas échéant, l'autorité européenne de tutelle.

Pour les projets Drupal menés au Luxembourg, découvrez mon offre Drupal Luxembourg (RAWeb, multilingue FR/DE/EN/LU, public comme privé) et ma ressource écosystème Drupal LU.

FAQ

SA-CORE-2026-004 : vos questions, mes réponses

La PSA-2026-05-18 est l'annonce préventive (Public Service Announcement) diffusée par la Drupal Security Team le 18 mai 2026, pour signaler à l'avance l'arrivée d'un correctif critique. L'advisory qui l'a suivie, SA-CORE-2026-004, est parue le 20 mai 2026 dans la fenêtre 17h-21h UTC. Elle ferme une injection SQL (CVE-2026-9082) située dans la couche Database abstraction API du noyau, qui ne menace que les sites sous PostgreSQL. La note atteint 20/25 sur le barème Drupal (Highly Critical) et le défaut est activable sans aucun compte. Drupal n'avait pas émis d'alerte d'une telle gravité depuis Drupalgeddon 2, en mars 2018.

Les branches 8.x, 9.x, 10.x et 11.x sont toutes vulnérables. Côté correctifs officiels : 11.3.10 (branche 11.3), 11.2.12 (branche 11.2), 11.1.10 (branche 11.1 hors support, patch best-effort), 10.6.9 (branche 10.6), 10.5.10 (branche 10.5) et 10.4.10 (branche 10.4 hors support, patch best-effort). Pour les 8.x et 9.x déjà retirées du support communautaire, Drupal publie à titre exceptionnel les patches fichiers 8.9.20 et 9.5.11, tout en invitant clairement à rejoindre une branche encore maintenue. Drupal 7, lui, n'est PAS concerné par cette faille.

L'injection SQL en tant que telle (CVE-2026-9082) ne frappe que PostgreSQL ; MySQL, MariaDB et SQLite échappent à ce chemin précis. Mais la livraison Drupal du 20 mai 2026 transporte aussi des correctifs critiques sur des dépendances tierces : Twig 3.26.0 (13 CVE, dont des injections de code PHP), Symfony 6.4.40 et 7.4.12 (10 CVE, dont injection d'URL et contournement d'HtmlSanitizer), Composer 2.9.8 et Underscore.js 1.13.8. Ces corrections valent pour n'importe quel moteur de base. Tout site Drupal en ligne doit donc être patché sous 72 heures, peu importe le SGBD utilisé.

Pour Drupal 8, le correctif officiel ne couvre que la branche 8.9. Sur un site en 8.0 à 8.8, deux chemins : remonter d'abord en 8.9.20 puis poser le patch officiel (2 à 4 jours en général, le temps de franchir cinq mineures), ou retoucher le patch à la main pour votre 8.x actuelle (0,5 à 1 jour). Cette adaptation manuelle est qualifiée par Drupal de « not guaranteed to work correctly, might introduce other bugs or regressions ». À mes yeux, le plus sain reste de migrer vers une branche encore soutenue comme Drupal 11.3, d'autant que Drupal 8 n'est plus maintenu depuis novembre 2021. Le détail figure dans la section dédiée plus haut.

Les branches 11.3 et 11.2 exigent au minimum PHP 8.3, avec MySQL 8.0, MariaDB 10.6, PostgreSQL 16 et SQLite 3.45. Les 10.6 et 10.5 réclament PHP 8.1 au plancher (8.3 ou plus conseillé), accompagné de MySQL 5.7.8, MariaDB 10.3.7, PostgreSQL 12 et SQLite 3.26. La 10.4 hors support veut PHP 8.1 minimum, la 9.5 PHP 7.4, et la 8.9 PHP 7.0.8 (7.3 et au-delà étant recommandés). Contrôler la version de PHP et celle de la base chez l'hébergeur est le préalable incontournable avant tout patch ou toute migration : si l'hébergement bloque, tout le calendrier se décale.

D'après l'advisory, un inconnu peut lancer l'attaque par une simple requête HTTP forgée, sans rien de plus que la présence de PostgreSQL. Au 21 mai 2026, aucune exploitation publique n'a été signalée, mais le risque se concentre sur les heures et les jours qui suivent la divulgation : c'est le laps de temps habituel avant l'apparition d'un proof-of-concept et de scans automatisés en masse. Souvenez-vous : Drupalgeddon 2 (mars 2018) avait fait tomber plus d'un million de sites Drupal en quelques heures. La PSA le dit sans ambiguïté : « exploits might be developed within hours or days ».

Drupal 7 n'est PAS visé par SA-CORE-2026-004, mais cela ne règle rien sur le fond : cette branche a quitté le support communautaire le 5 janvier 2025 et ne reçoit plus le moindre correctif de sécurité. Un site encore en Drupal 7 reste donc grand ouvert à toutes les failles repérées depuis cette date. Reportez-vous à mon guide fin de vie Drupal 7 pour les pistes de migration ou le support étendu HeroDevs.

Drupal Steward est un reverse-proxy WAF opéré par la Drupal Association, qui combine le ruleset OWASP mod_security et des règles taillées pour Drupal. Les sites qui y sont abonnés bénéficient d'un filtrage automatique des vecteurs connus de SA-CORE-2026-004. Cela ne remplace PAS le correctif : Steward sert de garde-fou temporaire, pas de solution de fond. Le patch doit être posé au plus vite.

Chez ReydenWeb, l'audit pré-patch standard représente 1 jour de travail expert. Vous repartez avec un mini-rapport : relevé des versions (PHP, MySQL/PostgreSQL, OS, hébergeur), état des modules contribués, inventaire des patches déjà posés via composer-patches, examen du code custom et de sa compatibilité, recommandations actionnables et chiffrage du patch ou de la migration. C'est le point d'entrée de toute intervention sur un site Drupal hors TMA. Pour les sites couverts par une TMA active, cet audit est compris dans le forfait annuel.

Les sources officielles que j'ai consultées

Ce contenu repose sur les sources primaires ci-dessous, que j'ai recoupées de mon côté au 21 mai 2026. Les liens pointent vers des sites externes et sont susceptibles d'évoluer.

Sources Drupal officielles

drupal.org/psa-2026-05-18 - Public Service Announcement
drupal.org/sa-core-2026-004 - Advisory complète
drupal.org/project/drupal/releases/11.3.10 - Release notes
drupal.org/project/drupal/releases/10.6.9 - Release notes
drupal.org/steward - Service Drupal Steward
drupal.org/schedule - Calendrier officiel des releases
drupal.org/docs/php-requirements - Prérequis PHP officiels
drupal.org/docs/database-server-requirements - Prérequis base de données

Bibliothèques tierces

NVD - CVE-2026-9082 - Base de données nationale CVE
Symfony Security Advisories - Symfony 6.4.40 / 7.4.12
GitHub - Twig Security Advisories - Twig 3.26.0

Autorités de régulation (FR / LU)

CNIL - Notification de violation de données personnelles (FR)
CNPD - Notification de violation de données personnelles (LU)
ANSSI - Notifications NIS2 (FR, via le CSIRT national)
HCPN - Notifications NIS2 (LU)

J'actualise cette page à mesure que les communications officielles paraissent. Si un élément factuel vous paraît inexact ou lacunaire, écrivez-moi à contact@reydenweb.fr.

Ressources liées

Un site Drupal à auditer ou à corriger ?
Échangeons.

Solliciter un audit

Échangeons sur l'audit et la correction de votre site Drupal

Nous contacter

Nous suivre