PSA Drupal SA-CORE-2026-014 : exécution de code critique dans Field UI, 14 octobre 2026
Cet article dit ce que l'avis contient, ce que le correctif public révèle de la faille, quelles versions installer, quoi faire en attendant, et comment vérifier après coup. Il s'adresse aux responsables de sites internet sous Drupal, aux DSI et aux directions de la communication qui pilotent un prestataire. Il s'appuie sur l'avis officiel, sur l'annonce préalable du 12 octobre et sur le code du correctif publié par la Drupal Security Team, relus le 14 octobre 2026 au soir.
- Exécution de code à distance dans Field UI, le module d'administration des champs, activé sur la quasi-totalité des sites web Drupal.
- Le cœur seul n'est pas exploitable, mais des modules contribués non nommés ouvrent plusieurs chemins, dont un sans authentification.
- Versions corrigées : 10.6.19, 11.3.19, 11.4.10. Les branches 10.5, 11.2 et antérieures ne reçoivent rien.
- Mesure d'attente officielle : désinstaller Field UI. Invisible pour les visiteurs, 10 secondes par site web.
- Drupal Steward protège en partie, l'avis le dit en toutes lettres : la mise à jour reste nécessaire.
Une publication en 3 dates
Les correctifs de sécurité du cœur de Drupal sortent un mercredi, et une annonce préalable prévient quand la publication sort de l'ordinaire. Cette fois, l'annonce est tombée un lundi, le correctif a suivi 2 jours plus tard, et les paquets sont arrivés dans le désordre.
Lundi 12 octobre : l'annonce préalable
PSA-2026-10-12 annonce une publication critique du cœur pour le 14 octobre entre 16h et 21h UTC, soit 18h à 23h à Paris, sur les branches 10.6, 11.3, 11.4 et la bêta de Drupal 12. Elle recommande de réserver du temps, « car des exploits peuvent être développés en quelques heures ou quelques jours », et de se mettre à jour sur le dernier correctif de sa branche avant la publication, pour ne pas découvrir un problème de montée de version le soir même.
Mercredi 14 octobre, 18h10 : l'avis
SA-CORE-2026-014, critique, 19 sur 25, exécution de code à distance, CVE-2026-108097. Le vecteur de risque dit l'essentiel : accès de complexité basique, aucune authentification requise, confidentialité et intégrité totalement compromises, pas d'exploit public connu au moment de la publication. Les tags Git des 3 versions corrigées avaient été posés à 12h58, heure de Paris, soit plus de 5 heures avant l'avis. À 19h25, 2 avis modérément critiques de script intersite, SA-CORE-2026-015 et SA-CORE-2026-016, ont suivi, corrigés par les mêmes versions.
Mercredi 14 octobre, le soir : les paquets
L'avis prévient que « l'empaquetage des versions peut encore être en cours » et conseille d'attendre 30 à 45 minutes. Dans les faits, drupal/core 11.4.10 était disponible sur Packagist avant la publication de l'avis, la 11.3.19 et la 10.6.19 n'y sont apparues qu'à 19h16, soit 1 heure et 6 minutes après l'avis, et le métapaquet drupal/core-recommended 11.3.19 y est apparu à 19h17, une minute plus tard. Une équipe qui a lancé composer update à 18h15 sur une branche 11.3 n'a rien trouvé : la version existait, le paquet pas encore.
La faille : une fonction de rappel lue dans le tableau de rendu
L'avis reste volontairement vague, c'est la règle pour une faille critique le jour de sa publication. Le code du correctif est public sur le dépôt du cœur, dans la comparaison entre les versions 11.3.18 et 11.3.19. Il touche 1 fichier pour cette faille, dans le module Field UI.
Ce que fait Field UI
Field UI est le module d'administration des champs : il fournit les écrans où l'on ajoute un champ à un type de contenu, où l'on règle son formulaire de saisie et son affichage. Le profil d'installation standard l'active, et la plupart des sites web le gardent en production parce que les éditeurs en ont besoin de temps en temps. Les visiteurs n'en voient jamais rien.
Ce que corrige la 11.3.19
Les écrans de Field UI affichent des tableaux de champs répartis par région. Pour chaque ligne, le code déterminait la région en appelant une fonction dont le nom était lu dans le tableau de rendu de la ligne elle-même. Le correctif supprime cet appel et lit une simple valeur, vérifiée contre la liste des régions connues. Autrement dit, avant le correctif, quiconque parvenait à faire rendre un tel tableau avec un nom de fonction de son choix faisait exécuter cette fonction par le serveur, avec le contenu de la ligne en argument.
Pourquoi il faut un module contribué
Le cœur ne laisse pas un visiteur écrire les clés techniques d'un tableau de rendu : c'est la leçon de SA-CORE-2018-002, dite Drupalgeddon 2, après laquelle le Form API et le traitement des requêtes filtrent ces clés. La faille du 14 octobre devient exploitable quand un module prend des données venues de la requête et les transforme en tableau de rendu sans ce filtrage. L'avis dit que plusieurs modules contribués le font, sans les nommer, et qu'un de ces chemins est ouvert aux anonymes. Du code sur mesure peut avoir le même défaut.
La conséquence pratique : un site web ne peut pas savoir, le jour de la publication, s'il est exposé. Il faudrait connaître la liste des modules concernés, que la Drupal Security Team garde pour elle tant que les sites web ne sont pas à jour. La seule réponse qui ne dépend pas de cette liste est de retirer Field UI, puis d'appliquer le correctif.
Qui est concerné, et quelle version installer
L'avis donne la plage des versions touchées : de 8.9.0 jusqu'aux dernières versions de chaque branche maintenue. Il existe 3 versions corrigées, et 3 branches ne reçoivent rien.
| Votre branche | Versions touchées | Version corrigée | Chemin |
|---|---|---|---|
| Drupal 11.4 | 11.4.0 à 11.4.9 | 11.4.10 | Mise à jour de correctif, disponible dès la publication |
| Drupal 11.3 | 11.0.0 à 11.3.18 | 11.3.19 | Mise à jour de correctif, paquet arrivé après la 11.4.10 |
| Drupal 10.6 | 8.9.0 à 10.6.18 | 10.6.19 | Mise à jour de correctif, puis migration avant la fin de vie du 9 décembre 2026 |
| Drupal 11.0 à 11.2 | Toutes | Aucune | Montée en 11.3 ou 11.4, puis correctif |
| Drupal 10.0 à 10.5 | Toutes | Aucune | Montée en 10.6, correctif, puis migration vers Drupal 11 |
| Drupal 8 et 9 | Toutes depuis 8.9.0 | Aucune, fin de vie | Migration, voir notre guide Drupal 11 |
| Drupal 12.0.0-alpha1 et beta1 | Toutes | 12.0.0-beta2 | Environnements de test uniquement |
Un site web resté sur une branche sans couverture ne peut pas appliquer ce correctif. C'est le cas le plus fréquent que nous rencontrons en reprise : un Drupal 10.3 ou 11.1 jamais monté, parce que « tout fonctionnait ». La montée de branche se fait en quelques heures sur un site sain, et c'est le préalable à toute sécurité. Notre guide de mai 2026 détaille le chemin version par version.
Que faire sans attendre, dans l'ordre
Le plan compte 4 étapes, dont la première se fait avant même que le paquet soit disponible. Chacune se termine par un livrable simple.
-
1. Couper le chemin d'attaque
Désinstaller Field UI en production :
drush pm:uninstall field_ui, puisdrush cr. L'élément de rendu vulnérable disparaît avec le module, les visiteurs ne voient rien, seuls les écrans d'administration des champs deviennent indisponibles. Les modules qui s'y greffent, comme Field Group ou Display Suite, perdent leurs onglets le temps de l'intervention. Livrable : les 3 commandes passées, l'heure notée. -
2. Mettre à jour sur un environnement de test
composer update drupal/core-recommended drupal/core-composer-scaffold drupal/core-project-message --with-all-dependencies, puisdrush updbetdrush cr. Si Composer ne trouve pas la version, le paquet n'est pas encore empaqueté : réessayer 30 minutes plus tard plutôt que de chercher une erreur de configuration. Vérifier l'accueil, une page de contenu, un formulaire et la connexion à l'administration. Livrable : une préproduction en 10.6.19, 11.3.19 ou 11.4.10. -
3. Déployer le soir même
Une sauvegarde de la base juste avant, le déploiement, le contrôle des mêmes pages qu'en test. Puis réactiver Field UI avec
drush pm:install field_ui. Attention à la configuration exportée : la désinstallation de l'étape 1 s'est inscrite danscore.extension.yml. Soit on réexporte après réinstallation, soit on ne réimporte rien entre les 2, sinon le déploiement remet le module en place avant le correctif. Livrable : la production corrigée, l'heure notée, un message au client. -
4. Vérifier qu'il ne s'est rien passé
Comptes administrateurs créés ou modifiés récemment, fichiers PHP ajoutés ou modifiés hors déploiement, tâches planifiées inconnues, requêtes inhabituelles dans les journaux du serveur web autour du 14 octobre. Plus le correctif arrive tard, plus cette étape compte. Livrable : une note de 5 lignes, même pour dire que tout est propre.
Ce que cette alerte dit de la maintenance Drupal
C'est la 4e alerte du cœur de niveau critique ou plus en 2026, après SA-CORE-2026-001 en avril, SA-CORE-2026-004 en mai, notée hautement critique, et SA-CORE-2026-005 en juin. C'est aussi la 2e publication annoncée par une PSA en un mois, après celle de Webform le 23 septembre. Les mêmes 3 leçons se dégagent à chaque fois.
L'annonce préalable sert à se préparer
L'écart de 2 jours entre la PSA et l'avis donne le temps de vérifier que le site web est sur le dernier correctif de sa branche, que la préproduction fonctionne, que la sauvegarde se restaure, et que quelqu'un est disponible le mercredi soir. Les équipes qui l'ont fait ont déployé en moins d'une heure. Les autres ont découvert le soir même qu'une montée de version bloquait, ou que personne n'avait les accès.
Les modules installés font la surface d'attaque
La faille est dans le cœur, mais c'est un module contribué qui la rend exploitable. Un site web Drupal en compte en général plusieurs dizaines. Sans inventaire à jour de ces modules, impossible de répondre à la question que pose chaque avis : suis-je concerné ? Et le jour où la Drupal Security Team publiera la liste des chemins d'exploitation, cet inventaire sera le seul moyen de savoir si une vérification après coup s'impose.
Une branche sans couverture ne reçoit aucun correctif
Les sites web en Drupal 10.5, 11.2 ou plus anciens n'ont reçu aucun correctif le 14 octobre, et n'en recevront pas. Chaque avis critique les laisse exposés sans recours. Drupal 10 entier s'arrête le 9 décembre 2026 : après cette date, la 10.6.19 sera dans la même situation. Notre plan de migration Drupal 10 et la feuille de route Drupal 12 donnent les échéances.
Sur les sites internet que nous maintenons, la procédure est la même à chaque avis : lecture de l'annonce préalable, vérification des versions, mesure d'attente dès la publication, mise à jour en test à l'arrivée du paquet, production dans la soirée, message au client avec l'heure et le numéro de l'avis. Chaque étape est prévue avant la publication, ce qui explique le délai court.
Obligations en France et au Luxembourg
Un correctif appliqué à temps ne déclenche aucune obligation. Une exploitation constatée qui expose des données personnelles avec un risque pour les personnes concernées, oui. Une exécution de code à distance donne accès à toute la base du site web, comptes et formulaires compris, ce qui place une compromission dans le champ du RGPD des 2 côtés de la frontière.
- France : en cas de violation de données personnelles, notification à la CNIL sous 72 heures, article 33 du RGPD. Les entités essentielles et importantes au sens de NIS2 notifient en plus l'ANSSI. Les organismes publics tenus par le RGAA n'ont pas d'obligation propre à cet avis, mais leur site web est souvent le premier visé.
- Luxembourg : même délai de 72 heures auprès de la CNPD. Pour NIS2, transposée par la loi du 5 mai 2026, la notification des incidents se fait auprès de l'ILR, le HCPN assurant la coordination nationale. Les acteurs régulés par la CSSF suivent en plus le régime de notification du secteur financier.
- Dans les 2 pays : la date de publication de l'avis, 14 octobre 2026 à 16h10 UTC, et la date d'application du correctif sont les 2 éléments qu'un régulateur demandera. Les noter au moment de l'intervention évite de les reconstituer sous pression.
Questions fréquentes sur l'alerte du 14 octobre
core.extension.yml, il faut la réexporter ou ne pas réimporter la configuration entre-temps, sinon le déploiement suivant réactive le module.
composer update qui ne trouve rien ne signifie pas que la version n'existe pas, le tag Git était déjà posé.
Sources officielles consultées
Cet article s'appuie sur l'avis et l'annonce préalable de la Drupal Security Team, et sur le code du correctif publié sur le dépôt officiel du cœur, relus le 14 octobre 2026 au soir. Les liens sont externes et peuvent évoluer.
Drupal Security Team
- drupal.org/psa-2026-10-12, l'annonce préalable du 12 octobre 2026
- SA-CORE-2026-014, l'avis, versions touchées et corrigées, mesure d'attente
- git.drupalcode.org, comparaison des versions 11.3.18 et 11.3.19, le code du correctif
- drupal.org, niveaux de risque, lecture du score 19 sur 25
- drupal.org/security, la liste des avis
- drupal.org/steward, périmètre du service Drupal Steward
Autorités de régulation
Cette ressource est mise à jour au fil des informations officielles. Si un point factuel vous semble erroné ou incomplet, écrivez-nous à contact@adevweb.com.
Pour aller plus loin
PSA Drupal SA-CONTRIB-2026-175 : Webform critique
L'alerte précédente, le 23 septembre 2026 : 36 avis en une soirée, dont une exécution de code dans Webform exploitable sans compte.
PSA Drupal SA-CORE-2026-004 : guide patch par version
La faille critique du cœur de mai 2026 et le chemin de mise à jour selon votre version, de Drupal 8 à 11.
Fin de vie Drupal 10 : plan de migration
Le 9 décembre 2026, Drupal 10 ne reçoit plus de correctif. Ce que ça change pour un site web en 10.6, et comment planifier la migration.
Notre offre Drupal
Correctifs de sécurité en urgence, reprise de sites web sans inventaire, migrations Drupal 7 à 12. Référence : vie-publique.fr, lead technique Drupal.
Un site Drupal à corriger sans attendre ?
Décrivez votre situation en quelques lignes : version du cœur, hébergement, présence ou non d'un prestataire. Un développeur senior vous répond sous 24 heures ouvrables, sans engagement.