Faille critique dans Drupal : le correctif est sorti, mais les sites restés sur une branche abandonnée n’y auront pas droit

L’équipe de sécurité de Drupal, le gestionnaire de contenu libre, a publié le 14 octobre 2026 une mise à jour critique de son cœur. Elle corrige une faille d’exécution de code à distance dans le module Field UI, notée 19/25 sur le barème de risque du projet. Le même jour, deux failles de moindre gravité du cœur et deux projets complémentaires ont aussi été corrigés. Les sites à jour n’ont qu’une version à installer. Ceux qui tournent encore sur une branche abandonnée, eux, ne recevront aucun correctif officiel.

Une exécution de code à distance est la catégorie de faille la plus redoutée : elle permet à un attaquant de faire exécuter ses propres instructions par le serveur qui héberge le site. Ici, le point faible se trouve dans Field UI, le module du cœur qui fournit l’interface de gestion des champs. C’est l’écran où l’on définit les informations que contient chaque type de contenu : un titre, une date, une image, un document joint. L’avis de sécurité classe la faille dans la catégorie « Critical », c’est-à-dire critique.

Au moins un chemin d’exploitation connu de la faille de Field UI ne demande aucune authentification.

La gravité réelle dépend toutefois de la configuration de chaque site. Selon l’avis, la faille n’est pas exploitable directement avec le cœur seul, mais plusieurs chemins d’exploitation sérieux existent dès que certains modules complémentaires, développés par la communauté, sont installés. L’un d’eux ne demande même pas de se connecter au site. Le code développé sur mesure peut lui aussi exposer la fonctionnalité vulnérable : un site réalisé par une agence, avec ses propres développements, n’est donc pas forcément à l’abri parce qu’il n’utilise que peu de modules. À sa publication, l’avis ne faisait en revanche état d’aucune exploitation confirmée.

Quelles versions mettre à jour

Les correctifs existent pour les trois branches encore maintenues : Drupal 11.4.10, 11.3.19 et 10.6.19, selon la branche utilisée. Un site à jour de sa branche n’a donc qu’une mise à jour mineure à installer, sans devoir passer d’abord à Drupal 11.4. Comme toujours, elle doit être précédée d’une sauvegarde complète des fichiers et de la base de données, puis suivie d’une vérification rapide des pages principales du site, en particulier des formulaires et de l’espace d’administration.

Le vrai problème concerne les sites restés sur une branche ancienne. Drupal 11.2.x et les versions antérieures de Drupal 11 sont en fin de vie et ne bénéficient plus d’aucune couverture de sécurité, tout comme Drupal 10.5.x et les versions antérieures de Drupal 10, sans parler de Drupal 8 et 9. Un site Drupal en fin de vie ne recevra aucun correctif officiel pour cette faille critique. Le blog spécialisé kgaut.net signale qu’un développeur a publié un correctif non officiel pour Drupal 9.5.11. L’auteur du blog précise ne pas l’avoir testé, et ce correctif n’est ni validé ni maintenu par l’équipe de sécurité de Drupal. Il ne couvre que la faille de Field UI et ne dispense pas d’une montée vers une version supportée.

Les administrateurs avaient été prévenus : l’équipe de sécurité de Drupal avait annoncé dès le 12 octobre, par un message public, la sortie d’une mise à jour critique du cœur. Cette pratique laisse aux responsables de sites le temps de s’organiser ; elle suppose en retour que quelqu’un surveille ces annonces.

Un contournement à manier avec prudence

En attendant de pouvoir mettre à jour, l’avis indique que désinstaller le module Field UI protège le site. Le blog kgaut.net, qui détaille la procédure, met en garde : la désactivation du module peut entraîner en cascade des suppressions de configuration. Sur un site dont la configuration est versionnée, il faut aussi veiller à ne pas exporter cette désinstallation par erreur. Les sites qui utilisent Drupal Steward ne sont, eux, protégés qu’en partie. Ce contournement ne protège pas non plus contre les deux autres failles du cœur publiées le même jour, qui ne sont corrigées que par la mise à jour.

Ces deux failles sont des « cross-site scripting » (XSS) : elles permettent d’injecter du code malveillant dans les pages affichées aux visiteurs ou aux administrateurs. La première touche le module Link, qui gère les liens, et la seconde le module Navigation, la nouvelle barre d’administration ; elles sont notées respectivement 13 et 12 sur 25. Deux projets complémentaires sont également corrigés. Le thème d’administration Gin, que kgaut.net décrit comme très répandu, doit passer en 4.1.4 ou 5.0.16. Entity List, qui embarque une copie du tableau de Field UI, souffre lui aussi d’une exécution de code à distance notée 19/25 et doit passer au moins en version 3.0.10.

Vérifier qu’on n’a pas déjà été visé

Mettre à jour ne suffit pas si le site a déjà été attaqué. Le blog kgaut.net conseille de surveiller dans les journaux du serveur des requêtes POST anonymes inhabituelles, c’est-à-dire des envois de formulaire par des visiteurs non connectés. Il recommande aussi de rechercher sur le disque des fichiers PHP récemment créés ou modifiés dans le dossier des fichiers publics du site ou à sa racine. Au moindre indice de compromission, il faut analyser la situation et restaurer le site depuis une sauvegarde saine : d’où l’intérêt de sauvegardes régulières, conservées hors du serveur et testées.

Pour une association, une collectivité ou une PME, ce type d’alerte rappelle qu’un site libre n’est pas un site sans entretien. Le logiciel est gratuit et son équipe de sécurité publie ses avis en toute transparence, mais encore faut-il qu’une personne identifiée suive ces annonces et applique les mises à jour sans tarder. Si votre site a été réalisé il y a quelques années par un prestataire, la première question à lui poser est simple : sur quelle branche de Drupal tourne-t-il, et est-elle encore maintenue ? Pour faire ce point, l’accompagnement bénévole et gratuit d’Azure Informatique peut vous aider, dans la mesure de nos disponibilités.