Drupal : SA-CORE-2026-014, faille critique d'exécution de code à distance dans Field UI

Mis à jour au fil de l'eau avec les dernières informations (patch D8 et D9 en fin de page)

L'équipe sécurité de Drupal l'avait annoncée le 12 octobre par la PSA-2026-10-12 : la mise à jour de sécurité critique du core est sortie ce mercredi 14 octobre 2026, avec l'avis SA-CORE-2026-014. Il s'agit d'une faille d'exécution de code à distance, exploitable sans authentification dans au moins un scénario connu. À appliquer sans attendre.

La faille en bref

• Identifiants : SA-CORE-2026-014, CVE-2026-108097.
• Type : exécution de code à distance (RCE).
• Criticité : « Critical », 19/25 (AC:Basic/A:None/CI:All/II:All/E:Theoretical/TD:Default).
• Module concerné : Field UI (field_ui), le module du core qui fournit l'interface de gestion des champs.

Le core seul n'expose pas directement la faille, mais l'avis précise que plusieurs chemins d'exploitation sérieux existent via des modules contrib, dont au moins un ne demande aucune authentification. Du code custom peut aussi exposer la fonctionnalité vulnérable. Autrement dit : même si votre site n'utilise « que » le core, ne pariez pas sur le fait de ne pas être exposé.

À noter, la cotation finale est plus sévère que celle annoncée dans la PSA : la complexité d'attaque passe de « Complex » à « Basic », et la vulnérabilité concerne les configurations par défaut ou courantes.

Versions concernées

• de 8.9.0 à 10.6.18 ;
• de 11.0.0 à 11.3.18 ;
• de 11.4.0 à 11.4.9 ;
• les versions alpha et beta de Drupal 12 antérieures à 12.0.0-beta2.

La plage remonte jusqu'à Drupal 8.9 : les branches en fin de vie (Drupal 8, Drupal 9, Drupal 10 avant 10.6, Drupal 11 avant 11.3) sont donc vulnérables, mais ne recevront pas de correctif.

Versions corrigées

• Drupal 11.4.x : 11.4.10 ;
• Drupal 11.3.x : 11.3.19 ;
• Drupal 10.6.x : 10.6.19.

Pour mettre à jour :

composer update "drupal/core-*" --with-dependencies
git diff composer.lock   # ne doit montrer que les paquets drupal/core*

Puis vérifier la version réellement installée :

drush status --field=drupal-version

L'avis prévient que la mise à disposition des paquets peut prendre un peu de temps : si Composer ne trouve pas encore la nouvelle version, patienter 30 à 45 minutes avant de réessayer.

Deux autres correctifs dans la même release

Ces versions ne corrigent pas qu'une faille. Elles embarquent aussi deux autres avis publiés le même jour, de moindre gravité, appliqués d'office par la mise à jour :

• SA-CORE-2026-015 (cross-site scripting, « Moderately critical » 13/25, CVE-2026-108515, une preuve de concept existe) : le filtrage des attributs HTML des liens (module Link) écarte désormais aussi les attributs HTMX (hx-* et data-hx-*), qui pouvaient servir à du cross-site scripting maintenant que HTMX est dans le core. Toutes les versions depuis 8.9.0 sont concernées. Effet de bord : un attribut hx-* saisi volontairement sur un lien sera retiré ;
• SA-CORE-2026-016 (cross-site scripting, « Moderately critical » 12/25, CVE-2026-108514) : les infobulles du module Navigation (la nouvelle barre d'administration) affichaient leur texte comme du HTML ; elles l'affichent désormais comme du texte brut. Seuls les sites où ce module est activé sont concernés (versions depuis 10.3.0), et l'attaquant doit pouvoir saisir des balises HTML avec certains attributs data-* ou administrer les menus. Effet de bord : du HTML volontaire dans une infobulle s'affichera tel quel.

Les versions 10.6.19 et 11.3.19 passent aussi CKEditor 5 en 47.6.3-drupal.1, une version maintenue par Drupal : un point de plus à vérifier en recette sur ces deux branches.

Et côté modules contrib

Deux avis contrib publiés le même jour corrigent le même code que le core, recopié dans ces projets :

• SA-CONTRIB-2026-218, Entity List : exécution de code à distance, « Critical » 19/25, CVE-2026-108099, même texte et même cotation que SA-CORE-2026-014. Le module embarque une copie du tableau de Field UI, corrigée de façon identique. Mettre à jour en 3.0.10 ;
• SA-CONTRIB-2026-219, thème d'administration Gin : cross-site scripting, « Moderately critical » 13/25, CVE-2026-110738. Gin a ses propres infobulles, corrigées comme celles du module Navigation (SA-CORE-2026-016). Mettre à jour en 4.1.4 (Gin 4) ou 5.0.16 (Gin 5).

Gin étant très répandu, il est probablement présent sur une bonne partie de vos sites : autant l'inclure dans la même mise à jour que le core.

composer update drupal/gin drupal/entity_list --with-dependencies

En attendant la mise à jour : désinstaller Field UI

Si vous ne pouvez pas mettre à jour immédiatement, l'avis indique que désinstaller le module Field UI protège le site le temps de faire la mise à jour :

drush pm:uninstall field_ui -y

Field UI ne sert qu'à l'interface d'administration des champs : sa désinstallation ne supprime ni les champs ni leurs données. Sur un site dont la config est versionnée, penser à ne pas exporter cette désinstallation par erreur, ou à réactiver le module une fois le correctif en place.

Ce contournement ne couvre que SA-CORE-2026-014 : les deux autres failles ne sont corrigées que par la mise à jour.

ATTENTION : la desactivation du module peut entrainer en cascade des suppressions de config, j'ai eu le cas, lisez bien ce qui suit la commande avant de confirmer.

Suis-je exposé ?

Le correctif porte sur la façon dont Field UI détermine la région de chaque ligne de ses tableaux (« Gérer l'affichage », « Gérer le formulaire ») : jusqu'ici, il appelait une fonction désignée dans le tableau de rendu, sans vérifier qu'elle était autorisée. Le core seul ne laisse pas de données extérieures arriver jusque-là ; le risque vient des modules contrib ou du code custom qui le permettraient. Quelques vérifications à faire, en plus de la mise à jour (qui reste la seule vraie protection) :

• Prioriser : patcher d'abord les sites publics qui ont beaucoup de modules contrib et des formulaires ouverts aux visiteurs anonymes.

• Relire son code custom : chercher les usages de l'élément field_ui_table et de la propriété #region_callback.

  grep -rn "field_ui_table\|#region_callback" web/modules/custom web/themes/custom

  Des modules contrib courants l'utilisent aussi (field_group, ui_patterns_ui) : leur logique reprend celle du core, et le correctif ne devrait rien changer à leur fonctionnement.

• Surveiller les jours qui suivent :
  • dans les logs d'accès, des requêtes POST anonymes inhabituelles, notamment avec des paramètres qui ressemblent à des propriétés de rendu Drupal (commençant par #, ou %23 une fois encodé) ;
  • dans le journal Drupal (watchdog), des erreurs PHP venant de FieldUiTable ;
  • sur le disque, des fichiers PHP récemment créés ou modifiés dans sites/*/files ou à la racine du site.

# Fichiers PHP créés ou modifiés ces 7 derniers jours dans les fichiers publics
find web/sites/*/files -name "*.php" -mtime -7

# Erreurs récentes liées à Field UI dans le journal Drupal
drush watchdog:show --severity=Error --count=200 | grep -i fielduitable

Si l'un de ces contrôles remonte quelque chose de suspect, le site doit être traité comme compromis : la mise à jour ne suffit plus, il faut analyser et restaurer depuis une sauvegarde saine.

Liens

• SA-CORE-2026-014 sur drupal.org
• SA-CORE-2026-015 sur drupal.org
• SA-CORE-2026-016 sur drupal.org
• SA-CONTRIB-2026-218 (Entity List) sur drupal.org
• SA-CONTRIB-2026-219 (Gin) sur drupal.org
• PSA-2026-10-12, l'annonce préalable
• Avis de sécurité du core Drupal
• Versions de Drupal core

Et pour un site en fin de vie ?

Pour les sites qui tournent encore sur une version qui ne reçoit plus de correctif, un développeur a publié un correctif non officiel pour Drupal 9.5.11. Il reprend, sur le fichier FieldUiTable.php, la même modification que la version officielle.

Je ne l'ai pas testé : il n'est ni validé ni maintenu par l'équipe sécurité de Drupal, il ne couvre que SA-CORE-2026-014 (pas les deux autres failles), et il ne dispense pas d'une montée vers une version supportée. À relire avant de l'appliquer, et à vos risques.

Et sur Drupal 8.9 ?

Le correctif ci-dessus s'applique aussi sur Drupal 8.9.20 (vérifié par un patch --dry-run, avec un léger décalage de lignes). Il s'applique depuis le dossier core/, ses chemins étant relatifs à celui-ci.

Attention toutefois : il utilise array_key_first(), qui n'existe qu'à partir de PHP 7.3. Drupal 8.9 tourne encore parfois sur un PHP plus ancien. Voici une variante de la même modification, sans ?? ni array_key_first(), à appliquer depuis le docroot (le dossier qui contient core/) avec patch -p1.

Cette variante, je l'ai appliquée en production sur un site Drupal 8.9.20 (PHP 7.4) voué à être décommissionné : le patch passe sans adaptation, le site répond normalement, aucune erreur n'est apparue dans les logs, et les pages « Gérer l'affichage » et « Gérer le formulaire » s'affichent toujours. Un seul site, donc pas une garantie pour le vôtre.

diff --git a/core/modules/field_ui/src/Element/FieldUiTable.php b/core/modules/field_ui/src/Element/FieldUiTable.php
--- a/core/modules/field_ui/src/Element/FieldUiTable.php
+++ b/core/modules/field_ui/src/Element/FieldUiTable.php
@@ -67,7 +67,13 @@
           unset($list[$name]);
 
           // Determine the region for the row.
-          $region_name = call_user_func_array($row['#region_callback'], [&$row]);
+          // SA-CORE-2026-014 : la region est lue dans la valeur de l'element,
+          // plus aucun callable n'est appele depuis le tableau de rendu.
+          $region_name = isset($row['region']['#value']) ? $row['region']['#value'] : '';
+          if (!isset($regions[$region_name])) {
+            $region_keys = array_keys($regions);
+            $region_name = isset($regions['hidden']) ? 'hidden' : reset($region_keys);
+          }
 
           // Add the element in the tree.
           $target = &$trees[$region_name][''];

Pour l'appliquer, en gardant la sauvegarde hors du docroot : une copie FieldUiTable.php.orig laissée à côté du fichier pourrait être servie telle quelle par le serveur web.

mkdir -p ~/backup-sa-core-2026-014
cp core/modules/field_ui/src/Element/FieldUiTable.php ~/backup-sa-core-2026-014/FieldUiTable.php.orig
patch --dry-run -p1 < SA-CORE-2026-014-d8.patch && patch -p1 < SA-CORE-2026-014-d8.patch
php -l core/modules/field_ui/src/Element/FieldUiTable.php
drush cr

Mêmes réserves que plus haut : non officiel, à relire, et uniquement pour gagner du temps sur un site voué à disparaître ou à migrer. Et si le site est déployé par Composer, un composer install écrasera la modification : la déclarer alors dans les patches du composer.json.