PSA Drupal SA-CORE-2026-004 : guide patch par version
Cet article décrit factuellement ce qui s'est passé, ce qui est corrigé, comment patcher selon votre version actuelle de Drupal, et les prérequis PHP / base de données à connaître. Il s'adresse aux DSI, CTO, responsables techniques et développeurs qui doivent prendre une décision rapide d'intervention sur un parc de sites Drupal. Nous le maintenons à jour au fil des informations officielles qui sortent.
- Faille : SQL Injection dans le composant Database abstraction API, sites PostgreSQL uniquement.
- Score : 20/25 sur l'échelle Drupal Risk (Highly Critical). Exploit anonyme, complexité d'accès faible.
- Versions corrigées : 11.3.10, 11.2.12, 10.6.9, 10.5.10. Patches best-effort pour 11.1.10, 10.4.10, 9.5.11, 8.9.20.
- Mises à jour embarquées : Twig 3.26.0, Symfony 6.4.40 / 7.4.12, Composer 2.9.8, Underscore.js 1.13.8. Concerne tous les sites Drupal, quel que soit le SGBD.
- Drupal 7 non affecté, mais en EOL depuis le 5 janvier 2025 (autres failles non corrigées).
La faille en détail
La vulnérabilité est référencée sous CVE-2026-9082, catégorie CWE-89 (« Improper Neutralization of Special Elements used in an SQL Command »). Elle se situe dans le composant Database abstraction API du cœur de Drupal, l'abstraction qui sert toutes les requêtes SQL générées par les modules core et contribués.
Caractéristiques officielles
- Type : SQL Injection (CWE-89)
- Composant : Database abstraction API (Drupal core)
- Base de données affectée : PostgreSQL uniquement (MySQL, MariaDB et SQLite ne sont pas vulnérables sur ce vecteur)
- Score Drupal Risk : 20/25 (Highly Critical)
- Décomposition : Access complexity = None, Authentication = None, Confidentiality impact = All non-public data, Integrity impact = All data modifiable
- Score CVSS 3.1 NVD : 6.5 (Medium). Divergence avec la cotation Drupal (20/25 Highly Critical), qui pondère plus fortement l'absence d'authentification dans son scoring interne.
- Vecteur d'attaque : requête HTTP forgée, anonyme, sans configuration particulière
- Exploitation in the wild au 21 mai 2026 : aucune observation publique, mais fenêtre critique de quelques jours après disclosure
Pourquoi PostgreSQL seul
Drupal utilise une couche d'abstraction unifiée pour ses requêtes, mais les drivers de base de données implémentent chacun leur propre logique de quoting et de préparation des requêtes. La faille réside dans une combinaison spécifique : un pattern d'encodage que MySQL et SQLite neutralisent par défaut, mais que PostgreSQL accepte. Sur les sites configurés avec d'autres SGBD, la faille existe dans le code mais n'est pas exploitable sur ce vecteur précis. Tous les sites Drupal sous PostgreSQL en production sont concernés en priorité absolue.
Pourquoi c'est aussi grave
Trois facteurs s'additionnent pour expliquer le score 20/25. Premier : l'exploitation est possible sans authentification, n'importe quel attaquant peut tenter l'exploit depuis Internet sans même créer un compte. Deuxième : la complexité d'accès est faible, pas besoin de configuration spécifique du site, de privilèges particuliers, ou de chaîne d'exploitation complexe. Troisième : une SQL Injection permet en théorie de lire toutes les données non-publiques (utilisateurs, contenus restreints, configuration), d'en modifier (création de comptes admin, prise de contrôle), et potentiellement de chaîner vers du RCE selon la configuration de la base. La PSA mentionne explicitement que « exploits might be developed within hours or days ».
Pas que PostgreSQL : Twig, Symfony, Composer embarqués
La release du 20 mai 2026 ne se limite pas au patch SQL Injection. Drupal a profité de la fenêtre pour intégrer plusieurs mises à jour de bibliothèques tierces, dont certaines sont elles-mêmes critiques. Un site Drupal sous MySQL ou MariaDB n'est pas vulnérable à la SQLi PostgreSQL, mais reste impacté par les CVE des dépendances embarquées : il doit donc patcher comme les autres.
Twig 3.26.0 (20 mai 2026)
- Sandbox bypass via __toString : PHP code injection critique en environnement multi-tenant
- HtmlDumper XSS sur les sorties debug
- HTML-output filters incorrectement déclarés is_safe (twig/extras)
- Spaceless filter HTML escape bypass
- Unbounded memoisation intl-extra (vecteur DoS)
- 13 advisories au total publiées simultanément 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 publiées simultanément : CVE-2026-45063, 45064, 45065, 45066, 45070, 45754, 45755, 45756, 46626, 47212
- Vecteurs : URL injection, HtmlSanitizer bypass, plusieurs failles côté HttpFoundation et Validator
- Drupal core est affecté par « some of these vulnerabilities » selon la formulation officielle
- Source : symfony.com/blog/category/security-advisories
Autres dépendances mises à jour
- Composer 2.9.8 : hardening sécurité (impact sur les pipelines CI/CD qui exécutent composer install au déploiement)
- Underscore.js 1.13.8 : hardening front-end (uniquement Drupal 10.6.9)
Conclusion pratique : la question « notre site est sous MySQL, on est tranquilles ? » est fausse. La SQL Injection PostgreSQL est le titre de l'advisory, mais les CVE Twig et Symfony embarquées impactent tous les sites Drupal. Le patch doit être déployé partout, sans distinction de SGBD, dans le délai de 72 heures recommandé par Drupal.
Versions affectées et versions corrigées
Toutes les versions Drupal 8.x, 9.x, 10.x et 11.x sont concernées. Drupal 7 n'est pas affecté par cette faille spécifique. Le tableau ci-dessous synthétise les versions corrigées officiellement publiées 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 |
Les patches « best-effort » pour les versions EOL (11.1, 10.4, 9.5, 8.9) sont une exception accordée par Drupal vu la criticité. La formulation officielle est claire : « provided as one-time best-effort, not guaranteed to work correctly, might introduce other bugs or regressions ». Pour les versions 11.0, 10.3 et antérieures, 9.0 à 9.4, et 8.0 à 8.8, il n'y a tout simplement aucun patch direct : il faut d'abord upgrader vers la dernière version de la branche, puis appliquer le patch.
Chemin de mise à jour selon votre version actuelle
Voici les arbres de décision concrets, du cas le plus simple (vous êtes sur la dernière version supportée) au cas le plus complexe (vous traversez plusieurs versions mineures EOL).
Vous êtes sur Drupal 11.3.x
Cas le plus simple. 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, puis drush updb et drush cr. Tester en préproduction. Durée typique : 2 à 4 heures avec validation. Aucun risque de régression majeur.
Vous êtes sur Drupal 11.2.x
Update direct vers 11.2.12 par la même commande Composer adaptée. Drupal 11.2 atteint sa fin de vie en juin 2026, donc à terme il faudra basculer en 11.3 avant l'EOL. Mais le patch sécurité immédiat suffit à neutraliser SA-CORE-2026-004.
Vous êtes sur Drupal 11.0 ou 11.1 (EOL)
Deux options. Option recommandée : upgrade direct vers 11.3.10 (Composer, conflits de dépendances à résoudre, tests). C'est l'occasion de rattraper le retard sur les minor releases manquées. Option d'urgence : appliquer le patch fichier 11.1.10 fourni en best-effort pour gagner 24h, puis planifier la migration vers 11.3 dans la semaine. Dans tous les cas, ne pas rester sur 11.0 ou 11.1 EOL au-delà du patch d'urgence.
Vous êtes sur Drupal 10.6.x
Update direct vers 10.6.9. Drupal 10.6 reçoit du support sécurité jusqu'à la sortie de Drupal 12 (déc. 2026). À planifier ensuite : la migration vers Drupal 11.3 ou l'attente de Drupal 12, selon votre stratégie. Voir notre guide Drupal 12 roadmap 2026.
Vous êtes sur Drupal 10.5.x (LTS)
Update direct vers 10.5.10. Drupal 10.5 est la version LTS-like de la branche 10, qui reçoit du support sécurité jusqu'en juin 2026. À planifier ensuite : la migration vers Drupal 10.6, Drupal 11.3 ou l'attente de Drupal 12. Pour le détail des dates et options, voir notre guide fin de vie Drupal 10.
Vous êtes sur Drupal 10.4 (EOL)
Option recommandée : upgrade direct vers 10.6.9 par Composer. Option d'urgence : patch fichier 10.4.10 fourni en best-effort. Drupal 10.4 ne reçoit plus de correctifs depuis la sortie de 10.5 et 10.6, vous accumulez les failles non corrigées. La migration vers 10.6 (ou directement Drupal 11.3) doit être planifiée dans la foulée.
Vous êtes sur Drupal 10.0, 10.1, 10.2 ou 10.3 (EOL)
Aucun patch direct. Il faut d'abord upgrader vers Drupal 10.5 ou 10.6 (Composer + tests), puis appliquer le patch sécurité de la version cible. C'est un projet de 2 à 5 jours selon l'état du code custom et des modules contribués. Le saut vers Drupal 11.3 directement peut aussi être pertinent si vous voulez éviter une double migration dans les 6 mois.
Vous êtes sur Drupal 9.x (EOL nov. 2023)
Drupal 9 est en fin de vie communautaire depuis le 1er novembre 2023. Le patch 9.5.11 est fourni en best-effort one-time, mais la situation de fond est qu'aucun correctif n'est publié sur Drupal 9 depuis 18 mois hors cas exceptionnel comme celui-ci. La cible doit être Drupal 11.3, qui est la prochaine LTS de fait pour les sites en migration depuis D9. La complexité dépend de la qualité du code initial : un site Drupal 9 bien maintenu jusqu'à 9.5.x sera plus simple à migrer qu'un 9.0 jamais updaté.
Vous êtes sur Drupal 8.x (EOL nov. 2021)
Cas typique d'un client qui nous a contactés cette semaine : site Drupal 8.4.8 toujours en production, jamais migré depuis 2017. Drupal 8 est en fin de vie communautaire depuis novembre 2021, soit plus de 4 ans sans correctifs réguliers. Le patch 8.9.20 fourni en best-effort suppose d'abord d'être sur la branche 8.9. Pour les sites 8.0 à 8.8, deux options :
- Option 1 - migration 8.x → 8.9.20 + patch officiel : durée 2 à 4 jours selon le code, traversée de plusieurs versions mineures (changements PHP requis, configuration management, modules contribués). C'est la voie officielle, le patch est garanti.
- Option 2 - adapter manuellement le patch sur la version 8.x actuelle : durée 0,5 à 1 jour. Permis par Drupal mais qualifié de « not guaranteed to work correctly ». Mitigation temporaire, ne change pas le fond.
- Option 3 - migration directe vers Drupal 11.3 : projet plus lourd (audit modules, refactor potentiel), mais résout le problème pour 4 ans. Souvent la meilleure ROI sur les sites en 8.x.
Vous êtes sur Drupal 7 (EOL janv. 2025)
Bonne et mauvaise nouvelle. Bonne : SA-CORE-2026-004 ne vous concerne pas, Drupal 7 utilise une architecture totalement différente du composant DB abstraction de Drupal 8+. Mauvaise : Drupal 7 est en fin de vie communautaire depuis le 5 janvier 2025, plus aucun correctif de sécurité n'est publié depuis cette date par la communauté. Vous accumulez 16 mois de failles non corrigées. Options : migration vers Drupal 11.3 (recommandée), migration vers WordPress si le projet ne justifie plus Drupal, ou support étendu payant chez HeroDevs. Voir notre guide fin de vie Drupal 7.
Prérequis PHP et base de données par version
Avant de patcher ou migrer, il faut vérifier que la version PHP et la base de données chez votre hébergeur sont compatibles avec la version cible. C'est le premier point à lever : un blocage hébergeur décale tout le reste du planning. Ce tableau synthétise les prérequis officiels Drupal, vérifiés sur drupal.org et les release notes individuelles. Pour les versions historiques (Drupal 8.0 à 8.8), certaines données proviennent 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 transitions majeures à connaître
- PHP 5.5.9 → 7.0.8 : bump appliqué dans Drupal 8.7.0 (mai 2019) pour les nouvelles installations, bloquant en update à partir de 8.8.0 (décembre 2019).
- PHP 7.3 → 7.4 : Drupal 9.4 (juin 2022) avertit sur 7.3, sécurité non garantie en dessous de 7.4.
- PHP 8.1 minimum : introduit avec Drupal 10.0 (déc. 2022). PHP 8.1.6 recommandé à cause d'un bug OPcache des premières 8.1.x.
- PHP 8.3 minimum : Drupal 11.0 (août 2024). PHP 8.4 recommandé à partir de 10.6 / 11.3.
- PHP 8.5 minimum : Drupal 12.0 (déc. 2026), avec compilation argon2 requise.
- Symfony : 3.4 (Drupal 8.4+), 4.4 (Drupal 9), 6.2 (Drupal 10.0), 7.1 (Drupal 11.0), 8.x attendu pour Drupal 12.
- Bases de données : le saut MySQL 5.7.8 / MariaDB 10.3.7 / PostgreSQL 10 / SQLite 3.26 a été effectif dans Drupal 8.8 et 9.0. Drupal 10.0 a poussé PostgreSQL à 12. Drupal 11.0 a poussé MySQL à 8, MariaDB à 10.6, PostgreSQL à 16, SQLite à 3.45.
Point pratique observé sur le terrain : en mai 2026, tous les hébergements mutualisés ne proposent pas encore PHP 8.4 par défaut, et certaines offres d'entrée de gamme plafonnent à PHP 8.2 ou 8.3. Sur les hébergements OVH, 1and1, Gandi ou InfomaniaK, la version PHP doit souvent être basculée manuellement depuis le panneau de gestion. C'est une vérification à mener avant d'engager le plan de migration applicatif, pas pendant.
Pour les sites en retard : les failles accumulées
SA-CORE-2026-004 n'est pas un événement isolé. Pour un site qui n'a pas été patché depuis sa sortie EOL, l'addition des failles accumulées peut être plus grave que la PSA en cours. Quelques jalons historiques de référence :
Drupalgeddon 2 - mars 2018 (SA-CORE-2018-002)
CVE-2018-7600, score 24/25 (Highly Critical). Faille RCE dans le Form API, exploitable par requête anonyme. Le PoC public a été publié dans les 48 heures suivant la disclosure. Plus d'un million de sites Drupal ont été compromis dans les semaines suivantes, principalement pour du cryptomining et du défaçage. C'est le précédent historique direct de SA-CORE-2026-004.
Drupalgeddon 3 - avril 2018 (SA-CORE-2018-004)
CVE-2018-7602, score 20/25 (Highly Critical). Faille RCE similaire dans le Form API, exploitable cette fois par un utilisateur authentifié. Publiée 3 semaines après Drupalgeddon 2 pour fermer un vecteur résiduel.
SA-CORE-2019-003 et années suivantes
Plusieurs advisories Highly Critical entre 2019 et 2023 (RCE, XSS persistant, access bypass), avec des scores 18-19/25 mais sans annonce PSA dédiée. Un site Drupal 8 jamais updaté depuis 2018 ou un Drupal 9 jamais updaté depuis 2022 a accumulé une dizaine de failles documentées, sans compter celles des modules contribués.
SA-CORE-2026-001, 002, 003
Trois advisories Drupal publiées au premier trimestre 2026 sur des vecteurs plus classiques (XSS, access bypass). Niveau de criticité moyen à élevé, intégrées dans les releases mineures de mars et avril 2026. Un site à jour des minor releases est déjà couvert sur ces points.
La leçon transversale : la maintenance Drupal n'est pas un coût optionnel. Un site en TMA active applique les patches dans les 24 à 72 heures qui suivent la disclosure. Un site hors TMA accumule mécaniquement les failles, et son coût de remise à niveau augmente exponentiellement avec le retard. Sur les missions d'audit que nous menons, un site Drupal 8.x ou 9.x oublié pendant 3 à 5 ans représente typiquement 5 à 15 jours de travail expert pour le rattraper, sans compter la mise en TMA récurrente.
Méthodologie d'audit avant patch ou migration
Voici la méthodologie que nous appliquons sur les missions d'urgence post-PSA, ou plus généralement pour cadrer une montée de version Drupal. Le livrable est un mini-rapport remis sous 24 à 48 heures, avec chiffrage précis et plan d'action.
- Inventaire infrastructure : version PHP exacte, version base de données, type de SGBD (PostgreSQL est priorité), version OS, hébergeur (mutualisé, VPS, cloud), accès SSH disponible ou non, environnement de préproduction iso-prod existant ou à créer.
- Version Drupal core : commande
drush core:statuspour la version exacte (différencier 8.4.0 et 8.4.8 dans le même environnement, les écarts sont parfois significatifs). - Inventaire modules contribués :
drush pm:list --status=enabled --type=module --no-core, croisé avec la liste des modules abandonnés sur drupal.org. Modules sans release récente ou marqués « abandoned » sont des bombes à retardement. - Audit code custom : modules custom dans
modules/custom/, thèmes custom, fichierssettings.phpetservices.yml, hooks anciens (hook_menu, etc.) qui sont des indicateurs de code legacy. - Patches existants :
composer-patches.jsonou sectionpatchesducomposer.json. Pour chaque patch : encore nécessaire (issue toujours ouverte sur drupal.org), mergé upstream (donc supprimable) ou obsolète ? - Pipeline de déploiement : Git en place, CI/CD configurée (GitLab, GitHub Actions, Jenkins, Bitbucket Pipelines), procédure de déploiement documentée, possibilité de rollback automatisé ?
- Sauvegardes : politique de backup en place, fréquence, test de restauration récent ? Sans backup testé, l'intervention sécurité est risquée.
- Trafic et exposition : trafic moyen quotidien, présence d'utilisateurs authentifiés, formulaires anonymes, CDN ou WAF en place (Cloudflare, Akamai, Drupal Steward) ?
- Données sensibles : présence de données personnelles, données de santé, données financières ? Le périmètre RGPD impacte le délai obligatoire de notification CNIL en cas de compromission (72h pour les données personnelles).
- Plan d'action : recommandation argumentée (patch immédiat, migration mineure, migration majeure, refonte complète), chiffrage en jours-homme, planning prévisionnel, points de validation client.
Sur les missions urgentes post-PSA, l'audit pré-patch standard chez nous est cadré à 1 jour de travail. Le livrable type : un mini-rapport de 4 à 6 pages avec les éléments ci-dessus, plus la recommandation chiffrée. Pour les clients en TMA Drupal active, cet audit est intégré au forfait : aucune facturation supplémentaire, l'intervention démarre immédiatement.
Que faire selon votre situation
Au-delà du patch immédiat, voici la stratégie que nous recommandons selon le profil de votre site. Ces recommandations s'appuient sur les missions Drupal que nous portons en France et au Luxembourg, dont la référence vie-publique.fr (DILA) pour le secteur public.
Site supporté à jour - tranquille
Vous êtes en Drupal 11.3, 11.2, 10.6 ou 10.5 et vous avez une TMA active. Vous patchez en 2 à 4 heures, vous validez en préproduction, vous déployez. C'est l'application normale d'une TMA professionnelle. Si vous n'avez pas de TMA, c'est l'occasion d'en mettre une en place : un événement comme SA-CORE-2026-004 ne doit pas dépendre d'une décision ponctuelle.
Site EOL récent (10.4, 11.1) - rattrapage rapide
Vous êtes en Drupal 10.4 ou 11.1 (EOL récent). Patch best-effort en urgence, puis migration vers la dernière version supportée de la branche dans la semaine. Le retard est limité, le rattrapage est mécanique : 2 à 5 jours selon le code custom et les modules contribués.
Site Drupal 9 - migration prioritaire
Drupal 9 est EOL depuis novembre 2023. Vous avez accumulé 18 mois de failles non corrigées. La cible recommandée est Drupal 11.3 directement (pas de détour par D10 qui sera EOL en décembre 2026). Projet typique 5 à 15 jours selon le code. La PSA d'aujourd'hui est l'occasion d'engager ce projet.
Site Drupal 8 - urgence + migration
Drupal 8 est EOL depuis 4 ans et demi. Stratégie en deux temps : patch d'urgence (best-effort 8.9.20 ou adaptation manuelle si site < 8.9) pour gagner 1 à 2 mois, puis migration vers Drupal 11.3. La migration directe vers D11 (sans passer par D9 ou D10) est souvent la meilleure ROI.
Site Drupal 7 - non concerné mais en danger
Vous n'êtes pas concerné par SA-CORE-2026-004, mais Drupal 7 est EOL depuis janvier 2025, soit 16 mois d'autres failles non corrigées. La PSA d'aujourd'hui est un signal : le risque est structurel, pas conjoncturel. Options : migration Drupal 11, migration WordPress si le projet ne le justifie plus, ou support étendu payant HeroDevs pour gagner du temps. Voir notre guide fin de vie Drupal 7.
Vous ne savez pas où vous en êtes
Cas fréquent : site Drupal repris d'un ancien prestataire, pas d'inventaire à jour, pas de pipeline de déploiement documenté. L'audit pré-patch (1 jour, cadré, livrable mini-rapport) est conçu pour cette situation. Il vous donne une visibilité claire avant de décider, et le chiffrage de l'intervention nécessaire.
Et au Luxembourg ?
La PSA Drupal s'applique à l'écosystème mondial, sans distinction de juridiction. Les entreprises luxembourgeoises tournant sous Drupal sont concernées de la même manière, avec deux particularités à considérer.
Notification CNPD en cas de compromission
En cas d'exploitation effective et de fuite de données personnelles, la CNPD (Commission nationale pour la protection des données) doit être notifiée dans les 72 heures. Le cadre est aligné sur le RGPD européen et donc équivalent à celui de la CNIL côté français, mais l'autorité de référence pour les responsables de traitement basés au Luxembourg est la CNPD. La notification se fait via le portail guichet.lu.
NIS2 et secteurs critiques
Pour les entités essentielles ou importantes au sens de la directive NIS2 transposée au Luxembourg (loi du 7 décembre 2023), la gestion d'une vulnérabilité Highly Critical entre dans le périmètre des incidents de cybersécurité notifiables. La HCPN (Haut-Commissariat à la Protection nationale) coordonne les notifications. Un site Drupal compromis affectant un service essentiel doit être déclaré au CSIRT national dans les délais NIS2 : 24h pour l'alerte précoce, 72h pour la notification d'incident, 1 mois pour le rapport final.
CSSF pour le secteur financier
Les acteurs régulés par la CSSF (Commission de surveillance du secteur financier) sont soumis à un régime spécifique de notification d'incident IT (circulaire CSSF 22/806 et règlement DORA pour les services financiers européens depuis janvier 2025). Pour un site Drupal exposé d'une banque, assurance ou PSF luxembourgeois, la chaîne de notification combine CNPD (volet personnel), CSSF (volet régulé), et le cas échéant l'autorité de tutelle européenne.
Pour les missions Drupal au Luxembourg, voir notre offre Drupal Luxembourg (RAWeb, multilingue FR/DE/EN/LU, secteur public et privé) et notre ressource écosystème Drupal LU.
Questions fréquentes sur SA-CORE-2026-004
Sources officielles consultées
Cet article s'appuie sur les sources primaires suivantes, vérifiées indépendamment au 21 mai 2026. Les liens sont externes et peuvent é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)
Cette ressource est mise à jour au fil des informations officielles. Si un point factuel vous semble erroné ou incomplet, contactez-nous à contact@adevweb.com.
Pour aller plus loin
TMA Drupal : le guide complet
La maintenance applique les patches sécurité dans les 24 à 72 heures suivant chaque advisory. Ce guide détaille ce qui doit être inclus dans votre contrat TMA.
Drupal 12 - roadmap 2026
Sortie cible 7 décembre 2026, prérequis PHP 8.5, Symfony 8, modules retirés. Tout pour planifier votre prochaine montée de version majeure.
Fin de vie Drupal 10 - 9 décembre 2026
Drupal 10 cesse d'être maintenu en décembre 2026. Calendrier précis, options de migration vers Drupal 11 ou 12, prérequis et coût.
Drupal 7 en fin de vie : quelles options ?
Drupal 7 EOL depuis janvier 2025. Si vous êtes encore en D7, c'est la première question à traiter. Migration, support étendu HeroDevs ou rebuild.
Notre offre Drupal
Migrations Drupal 7 à 12, patches sécurité d'urgence, modules custom, accessibilité RGAA, intégration DSFR. Référence : vie-publique.fr (DILA).
Drupal au Luxembourg
Missions Drupal au Luxembourg avec perspective réglementaire locale : CNPD, NIS2, CSSF, RAWeb. Multilingue FR / DE / EN / LU.
Un site Drupal à auditer ou patcher ?
Parlons-en.
