L’essentiel
Tout site Drupal 10 ou 11 maintenu doit passer dès maintenant en 10.6.19, 11.3.19 ou 11.4.10. La CVE-2026-108097, publiée le 14 octobre 2026, est une faille critique d’exécution de code à distance (RCE) dans le module Field UI du cœur. Le cœur seul n’est pas exploitable, mais des modules contrib courants ouvrent plusieurs chemins, dont au moins un sans connexion. Si Drupal fait tourner votre application web, appliquez le correctif cette semaine.
Qu’a publié Drupal ?
Le 14 octobre 2026, la Drupal Security Team a publié le bulletin SA-CORE-2026-014 consacré à la CVE-2026-108097, une vulnérabilité d’exécution de code à distance dans Field UI, le module du cœur derrière les écrans d’administration où les intégrateurs ajoutent des champs et règlent l’affichage des contenus. L’équipe lui attribue 19 sur 25 sur sa propre échelle de risque : complexité d’attaque faible, aucune authentification requise, impact complet en lecture et en écriture sur les données du site. À la publication, l’exploitation était jugée théorique.
Le même cycle a livré SA-CONTRIB-2026-218 pour Entity List, un module contrib qui génère des listes d’entités sans Views. Sa faille, CVE-2026-108099, porte la même note critique 19/25 et suit le même schéma : inexploitable par le module seul, mais atteignable via d’autres modules, dont au moins un chemin sans connexion. Comme l’a rapporté BleepingComputer le 17 octobre, l’équipe de sécurité a averti les administrateurs que des exploits fonctionnels « pourraient être développés en quelques heures ou jours » après la publication.
Comment fonctionne la faille Field UI ?
Drupal construit ses pages à partir de render arrays, des structures PHP que le cœur transforme ensuite en HTML. Les analyses techniques publiées du correctif situent la cause dans le rendu des tableaux de Field UI : lors de l’étape de pré-rendu, un callable PHP transporté dans la propriété #region_callback de chaque ligne était exécuté sans vérifier de quel callable il s’agissait. Si un attaquant peut influencer cette propriété, il peut faire exécuter au serveur la fonction de son choix.
Le cœur ne transmet jamais de lui-même cette propriété à un visiteur anonyme, d’où la mention selon laquelle le cœur seul n’est pas exploitable. Le risque vient des modules contrib et du code sur mesure qui injectent des données contrôlées par l’utilisateur dans des render arrays. Drupal évoque « plusieurs chemins d’exploitation graves » de ce type : l’exposition réelle d’un site dépend donc de sa liste de modules, pas de sa version du cœur.
Quels sites sont exposés ?
Toutes les branches maintenues étaient touchées : Drupal 10 de 8.9.0 jusqu’à 10.6.18, et Drupal 11 jusqu’à 11.3.18 et 11.4.9. Drupal fait tourner plus d’un million de sites dans le monde, avec un usage marqué dans le secteur public, l’enseignement supérieur, le monde associatif et les équipes marketing des grands comptes. Même en hébergement infogéré, la mise à jour du cœur doit être intégrée à votre base de code puis déployée.
Le cas délicat, ce sont les sites encore sous Drupal 8 ou 9. La plage vulnérable commence à 8.9.0, mais ces deux versions sont en fin de vie et ne reçoivent aucun correctif. Il reste alors à désinstaller Field UI immédiatement et à planifier la migration sans doute repoussée depuis trop longtemps — un vrai projet de modernisation applicative, pas une correction d’une ligne.
Qu’est-ce que cela change pour les organisations françaises ?
La leçon dépasse Drupal : les failles critiques des CMS et frameworks se logent de plus en plus entre un cœur d’apparence sûre et les extensions qui s’y greffent. Votre surface d’attaque est fixée par votre arbre de dépendances. Un inventaire à jour des modules contrib, du code spécifique et de leurs versions est la première chose dont vous avez besoin lorsqu’un tel bulletin tombe ; sans lui, la première journée d’un correctif critique se passe à reconstituer ce qui tourne en production.
À faire cette semaine
- Mettre à jour le cœur. Passez en 10.6.19, 11.3.19 ou 11.4.10 avec
composer update drupal/core-recommended --with-dependencies, puis lancez les mises à jour de base de données et videz les caches. - Mettre à jour Entity List. Si le module est installé, passez-le en 3.0.10.
- Atténuer là où vous ne pouvez pas corriger. Désinstallez Field UI (
drush pm:uninstall field_ui) ; la configuration des champs est conservée et le module peut être réactivé après la mise à jour. - Inventorier vos modules. Recensez chaque module contrib et personnalisé qui construit des render arrays à partir de données de requête, et traitez en priorité les sites dotés de formulaires publics ou de points d’accès anonymes.
- Contrôler les sites en fin de vie. Repérez les installations Drupal 8 ou 9, retirez Field UI et fixez un plan de migration daté.
- Surveiller vos journaux. Recherchez des requêtes inhabituelles vers les formulaires et points AJAX, ainsi que de nouveaux fichiers PHP ou tâches cron apparus après le 14 octobre — et consignez tout constat utile à une éventuelle notification CNIL.
Questions fréquentes
Qu’est-ce que la CVE-2026-108097 ?
La CVE-2026-108097 est une vulnérabilité d’exécution de code à distance dans le module Field UI du cœur Drupal, publiée le 14 octobre 2026 dans le bulletin SA-CORE-2026-014. La Drupal Security Team la classe critique, 19 sur 25. Le cœur seul ne permet pas de l’exploiter, mais des modules contrib ou du code personnalisé peuvent l’exposer, et au moins un chemin d’exploitation connu ne requiert aucune authentification.
Quelles versions de Drupal sont concernées et corrigées ?
Sont concernées Drupal 8.9.0 à 10.6.18, Drupal 11.0.0 à 11.3.18 et Drupal 11.4.0 à 11.4.9. Les versions corrigées sont 10.6.19, 11.3.19 et 11.4.10. Drupal 8 et 9 sont en fin de vie et ne reçoivent aucun correctif de sécurité.
La CVE-2026-108097 est-elle exploitée ?
Lors de la publication, la Drupal Security Team jugeait l’exploitation théorique, et la couverture que nous avons consultée jusqu’au 17 octobre 2026 ne signalait pas d’attaques actives. L’équipe a toutefois prévenu que des exploits pourraient apparaître en quelques heures ou jours : il faut donc corriger sans attendre d’attaques confirmées.
Que faire si nous ne pouvons pas mettre Drupal à jour tout de suite ?
Désinstaller le module du cœur Field UI (field_ui) protège le site en attendant la mise à jour. La configuration des champs est conservée et le module peut être réactivé après le correctif. Drupal Steward n’offre qu’une protection partielle et ne remplace pas la mise à jour.
Quelle est la faille Entity List publiée le même jour ?
Le même jour, Drupal a publié SA-CONTRIB-2026-218 pour le module contrib Entity List. Sa faille, CVE-2026-108099, est elle aussi une RCE critique (19/25) atteignable via d’autres modules, dont au moins un chemin sans authentification. Elle est corrigée dans Entity List 3.0.10.
Sources
Drupal Security Team — SA-CORE-2026-014 : Drupal core, Critical, Remote code execution (14 octobre 2026)
Drupal Security Team — SA-CONTRIB-2026-218 : Entity List, Critical, Remote code execution (14 octobre 2026)
BleepingComputer — Drupal patches critical RCE flaws, warns exploits may emerge soon (17 octobre 2026)
The Hacker News — Drupal Patches Critical Field UI Flaw With Unauthenticated RCE Path via Contributed Modules (octobre 2026)