Développement Web

Faille Drupal du 14 octobre 2026 : quelle version installer, en trois phrases

Si votre site tourne en Drupal 11.4, installez la 11.4.10 ; en 11.3, la 11.3.19 ; en 10.6, la 10.6.19. Si vous êtes sur une branche plus ancienne (11.2, 10.5 ou avant), il n’existe aucun correctif pour vous : il faut changer de branche, et autant viser directement la 11.4.10. Dans tous les cas, vérifiez ensuite à part le module Entity List et le thème Gin, que la mise à jour du core ne corrige pas.

La faille principale, SA-CORE-2026-014 (CVE-2026-108097), est une exécution de code à distance dans le module core Field UI, notée critique à 19/25. L’équipe sécurité précise que le core seul n’est pas directement exploitable, mais que plusieurs chemins d’exploitation passent par des modules contribués, dont au moins un sans authentification. Du code custom peut aussi exposer la fonctionnalité vulnérable. Elle avait été annoncée deux jours plus tôt par le PSA-2026-10-12, qui prévenait que des exploits pourraient apparaître « en quelques heures ou quelques jours ». À la publication, aucune exploitation active n’était signalée.

Mon site est-il concerné par SA-CORE-2026-014 ?

Presque certainement, s’il n’a pas été mis à jour depuis le 14 octobre. Toutes les versions de Drupal 8.9.0 à 10.6.18, de 11.0.0 à 11.3.18 et de 11.4.0 à 11.4.9 sont touchées, ainsi que les préversions 12.0.0 jusqu’à la beta1 (corrigé en 12.0.0-beta2). Field UI est activé sur la quasi-totalité des sites, puisque c’est lui qui fournit les écrans « Gérer les champs » et « Gérer l’affichage ». Pour connaître votre version :

# Version du core installée (depuis la racine du projet)
composer show drupal/core | grep versions

# Ou via Drush
vendor/bin/drush status --field=drupal-version

# Field UI est-il activé ?
vendor/bin/drush pm:list --status=enabled --filter=field_ui

Si vous restez dans votre branche (11.4.x vers 11.4.10, par exemple), la mise à jour est un correctif de sécurité pur : les notes de version de la 11.4.10 précisent qu’aucune autre correction n’est incluse.

# Mise à jour dans la branche courante (Drupal 10.6, 11.3 ou 11.4)
composer update "drupal/core-*" --with-all-dependencies
vendor/bin/drush updatedb -y
vendor/bin/drush cache:rebuild

Les cinq avis du 14 octobre et pourquoi « mettre à jour le core » ne suffit pas

Le 14 octobre 2026 n’a pas apporté une faille, mais cinq avis de sécurité. Trois concernent le core et sont corrigés par les mêmes versions 11.4.10, 11.3.19 et 10.6.19. Deux concernent des projets contribués, qui ont leur propre cycle de version : tant que vous ne les mettez pas à jour explicitement, ils restent vulnérables, même sur un core à jour.

Entity List : la seconde exécution de code à distance du jour

SA-CONTRIB-2026-218 (CVE-2026-108099) porte exactement le même score que la faille du core, 19/25, et le même profil : le module seul n’est pas directement exploitable, des chemins d’exploitation existent via d’autres modules contribués, dont au moins un sans authentification, et du code custom peut exposer la fonctionnalité. Les deux avis partagent d’ailleurs une partie de leurs rapporteurs. Toutes les versions antérieures à la 3.0.10 sont touchées.

Entity List permet de construire des listes de contenus sans passer par Views. Il est peu répandu (environ 90 sites déclarés sur drupal.org) et ses mainteneurs le décrivent comme en maintenance minimale. C’est précisément le profil de module qu’on oublie : installé il y a quelques années par un prestataire, jamais revu depuis, et absent des radars quand tout le monde parle « du » correctif Drupal.

Gin, Link et Navigation : des XSS qui demandent un compte

Les trois autres avis sont modérément critiques et ne sont pas exploitables par un visiteur anonyme. La faille du thème d’administration Gin et celle du module core Navigation exigent un rôle autorisé à saisir des balises HTML avec certains attributs data-, ou la permission administer menu. Celle de Link ne touche que des configurations peu courantes. Gin est le thème d’administration par défaut de Drupal CMS : si votre site en est issu, il est concerné.

# Entity List et Gin sont-ils installés, et en quelle version ?
composer show drupal/entity_list drupal/gin 2>/dev/null | grep -E '^(name|versions)'

# Mise à jour (Entity List 3.0.10, Gin 4.1.4 ou 5.0.16 selon la branche)
composer update drupal/entity_list drupal/gin --with-all-dependencies
vendor/bin/drush updatedb -y
vendor/bin/drush cache:rebuild

Plus largement, profitez de l’intervention pour lister tout ce qui attend une mise à jour de sécurité. Sur un site non suivi depuis plusieurs mois, Entity List et Gin sont rarement les seuls en retard.

# Paquets Drupal disposant d’une mise à jour, contrib compris
composer outdated "drupal/*"

# Vulnérabilités connues dans les dépendances installées
composer audit

Sites en 11.2, 10.5 ou avant : changer de branche avant le 7 décembre 2026

Les branches 11.2.x et antérieures, 10.5.x et antérieures, ainsi que Drupal 8 et 9, sont en fin de vie : elles sont vulnérables et ne recevront aucun correctif. La seule issue est de monter sur une branche supportée, au minimum la 11.3.19 ou la 10.6.19.

Ce minimum a une date de péremption. Selon le calendrier officiel du core, les branches 11.3.x et 10.6.x perdent leur support de sécurité la semaine du 7 décembre 2026, la même semaine que la sortie de Drupal 11.5.0 et 12.0.0. Drupal 10 arrive en fin de vie le 9 décembre 2026. Un site qui passe aujourd’hui de 11.2 à 11.3.19 devra donc refaire une montée de version mineure dans sept semaines. Viser directement la 11.4.10 évite ce double travail.

# Changement de branche, exemple de 11.2.x vers 11.4.10
# (ajouter drupal/core-dev avec --dev s’il figure dans require-dev)
composer require "drupal/core-recommended:^11.4.10" "drupal/core-composer-scaffold:^11.4.10" --update-with-all-dependencies
vendor/bin/drush updatedb -y
vendor/bin/drush cache:rebuild

Une montée de version mineure n’est pas un correctif de sécurité : elle peut embarquer des mises à jour de schéma, des dépréciations et des contraintes de dépendances qui bloquent Composer. Testez-la sur une copie du site, et appliquez la mesure d’attente ci-dessous sur la production pendant ce temps.

Pour un site encore en Drupal 10, la question est plus large : le 9 décembre, la 10.6.19 sera elle aussi sans support. Le passage en 10.6.19 ferme la faille, pas le sujet. Nous détaillons le budget d’une migration dans Migration Drupal 10 vers Drupal 11 : ce que ça coûte réellement.

Drupal 7 n’est pas mentionné dans l’avis officiel, sa fin de vie étant actée depuis janvier 2025. Les fournisseurs de support étendu ont toutefois réagi : Pantheon, avec Tag1 Consulting, a publié un Drupal 7.107 qui reporte le correctif de Field UI.

Peut-on désactiver Field UI en attendant la mise à jour Drupal ?

Oui, et c’est la mesure d’attente recommandée par l’avis lui-même : désinstaller le module core Field UI (field_ui) protège le site le temps de le mettre à jour. C’est la bonne option quand la mise à jour ne peut pas partir dans l’heure, typiquement pour un site en fin de branche qui exige une vraie montée de version.

# Désinstaller Field UI (sans -y : relisez la liste des modules
# dépendants que Drush propose de désinstaller avec lui)
vendor/bin/drush pm:uninstall field_ui

# Après la mise à jour du core, le réinstaller
vendor/bin/drush pm:install field_ui

Ce que vous perdez est limité : les champs, leur stockage, leurs données et les modes d’affichage restent en place, le site fonctionne normalement. Seuls disparaissent les écrans d’administration « Gérer les champs », « Gérer le formulaire » et « Gérer l’affichage » jusqu’à la réinstallation. Trois effets de bord sont à connaître :

• Les permissions fournies par Field UI (du type administer node fields) sont retirées des rôles à la désinstallation et ne reviennent pas seules à la réinstallation.
• La configuration field_ui.settings, qui porte notamment le préfixe des noms de champs, est supprimée et repart des valeurs par défaut.
• Si Drush liste d’autres modules à désinstaller en cascade, leur configuration sera supprimée aussi : dans ce cas, mesurez l’impact avant de valider.

Si votre site utilise Drupal Steward, il est protégé contre une partie des vecteurs connus, mais pas tous, de l’aveu même de l’équipe sécurité. Steward fait gagner du temps, il ne dispense pas de la mise à jour.

Code custom : #region_callback n’est plus appelé par Field UI

L’avis cite le code custom comme vecteur possible, sans plus de détail. Le correctif, lui, est public et tient en quelques lignes dans core/modules/field_ui/src/Element/FieldUiTable.php, identiques sur les branches 10.6.19 et 11.4.10 : la méthode tablePreRender() n’exécute plus la fonction déclarée dans la clé #region_callback d’une ligne de tableau. Elle lit désormais la région dans la valeur de l’élément region de la ligne.

-        $region_name = call_user_func_array($row['#region_callback'], [&$row]);
+        $region_name = $row['region']['#value'] ?? '';
+        if (!isset($regions[$region_name])) {
+          $region_name = isset($regions['hidden']) ? 'hidden' : array_key_first($regions);
+        }

Deux conséquences pratiques, qu’aucun résumé de l’avis ne mentionne :

• Un module custom qui ajoute ses propres lignes dans les tableaux « Gérer l’affichage » ou « Gérer le formulaire » et calcule leur région via #region_callback ne sera plus pris en compte : la ligne bascule dans la région hidden, ou dans la première région disponible.
• Même logique pour un module contribué qui insère des lignes dans ces écrans : après la mise à jour, ouvrez « Gérer l’affichage » sur un ou deux types de contenu et vérifiez que chaque élément est resté dans sa région.

# Repérer le code custom qui dépend de #region_callback
# ou qui réutilise les formulaires et éléments de Field UI
grep -rnE "#region_callback|FieldUiTable|field_ui_table" \
  web/modules/custom web/themes/custom

Pantheon signale le même changement de comportement dans son Drupal 7.107. Ce n’est donc pas un détail d’implémentation : c’est le cœur du correctif, et la première chose à tester sur un site qui personnalise l’administration des champs.

Notre avis

Votre site Drupal n’a pas encore reçu ces correctifs, ou vous ne savez pas qui s’en charge ? Nous intervenons en urgence sur des sites que nous ne connaissons pas encore, puis nous en assurons le suivi dans la durée. Découvrir notre offre de maintenance TMA Drupal ou nous contacter pour une mise à jour de sécurité.