Deux alertes de sécurité critiques viennent de tomber à une semaine d'écart : une faille dans le code de Drupal, puis une faille dans le moteur PHP lui-même. Pour un responsable technique qui opère un site Drupal, la question concrète est simple : qui doit agir, dans quel ordre, et avec quelle urgence. Cette mise à jour sécurité PHP Drupal tombe juste avant deux échéances fermes de fin d'année : la fin de vie de PHP 8.2 et celle de Drupal 10, les deux fixées pour décembre 2026.
Deux alertes critiques coup sur coup : PHP2Shell et la faille Field UI de Drupal
Les deux failles n'ont rien en commun, sauf leur calendrier. L'une touche PHP, l'autre touche Drupal.
PHP2Shell (CVE-2026-109618 et CVE-2026-109619) : une faille dans PHP lui-même
Le 21 octobre 2026, l'équipe PHP a publié deux avis de sécurité coordonnés, regroupés sous le nom « PHP2Shell ». CVE-2026-109618 permet une exécution de code à distance par corruption d'état, déclenchée par une condition de manque de mémoire pendant le traitement d'une requête multipart. CVE-2026-109619 exploite un état global devenu obsolète, réutilisable par une requête suivante traitée par le même worker. Les deux failles sont notées 9,2 sur 10 en CVSS v4.0 et ne demandent aucune authentification.
Le changelog officiel de PHP date du 22 octobre 2026 les versions 8.4.27 et 8.5.12, un jour après l'annonce ; les branches 8.2 et 8.3 sont corrigées respectivement en 8.2.35 et 8.3.36. Au moment de son alerte du 21 octobre, l'agence américaine CISA n'avait observé aucune exploitation réussie dans la nature. Elle recommandait malgré tout de corriger en priorité les systèmes exposés sur Internet, ce qui inclut tout site Drupal accessible depuis Internet.
SA-CORE-2026-014 : la faille critique du module Field UI dans Drupal core
Une semaine plus tôt, le 14 octobre 2026, Drupal a publié SA-CORE-2026-014 (CVE-2026-108097). Il s'agit d'une exécution de code à distance dans le module Field UI, avec un risque noté 19 sur 25 par Drupal et au moins un vecteur exploitable sans authentification. Cette faille touche les versions 8.9.0 à 10.6.18, 11.0.0 à 11.3.18 et 11.4.0 à 11.4.9, et se corrige en passant respectivement en 10.6.19, 11.3.19 ou 11.4.10.
Pourquoi les deux correctifs sont nécessaires
Le Drupal Security Team le rappelle dans son PSA du 20 octobre : pour PHP2Shell, mettre à jour PHP est la seule mitigation complète. Une mise à jour de Drupal ne la corrige pas, puisque la faille vit dans le moteur PHP, pas dans le code de Drupal. À l'inverse, SA-CORE-2026-014 vit dans Field UI, un module de Drupal core : seule une mise à jour de Drupal la referme. Les deux correctifs sont nécessaires, et aucun des deux ne remplace l'autre.
Ce qui change d'ici fin 2026 : calendrier PHP et fin de vie de Drupal 10
Ces deux alertes tombent à un moment particulier du calendrier : deux échéances de fin de support arrivent la même semaine, en décembre 2026.
Le calendrier de support de PHP 8.2 à 8.5
Le tableau officiel des versions supportées fixe la fin du support sécurité de PHP 8.2 au 31 décembre 2026. PHP 8.3 suit au 31 décembre 2027, PHP 8.4 au 31 décembre 2028 et PHP 8.5 au 31 décembre 2029. Un site encore sur PHP 8.2 après le correctif PHP2Shell n'a donc que quelques semaines de répit avant de devoir, de toute façon, migrer vers une version supérieure.
Drupal 10 s'arrête le 9 décembre 2026, Drupal 11.0 exige déjà PHP 8.3
Selon le calendrier de publication officiel de Drupal, Drupal 10 atteint sa fin de vie le 9 décembre 2026, la même semaine que la sortie de Drupal 12. Un site encore sous Drupal 10 à cette date ne recevra plus de correctif de sécurité pour son noyau, quelle que soit la gravité de la prochaine faille découverte.
Migrer vers Drupal 11 ne se fait pas sans toucher à PHP. Drupal a annoncé dès 2024 que Drupal 11.0 exige au minimum PHP 8.3. Depuis Drupal 9.4, le projet applique aussi une politique qui abandonne automatiquement le support des versions de PHP que l'équipe PHP elle-même ne maintient plus. Autrement dit, rester sur Drupal 10 et PHP 8.2 n'est plus une option stable passé décembre 2026, dans aucun des deux sens.
Comment opérer la mise à jour sans tout casser
Face à deux failles distinctes et deux échéances qui convergent, l'ordre des opérations compte autant que la rapidité d'exécution.
Qui doit agir : vous, votre hébergeur, ou les deux
La version de PHP est souvent gérée par l'hébergeur, en particulier sur une infrastructure mutualisée ou un PaaS. Si c'est votre cas, vérifiez auprès de lui que la version déployée inclut bien le correctif PHP2Shell (8.2.35, 8.3.36, 8.4.27 ou 8.5.12 selon votre branche), plutôt que de supposer qu'il l'a déjà appliqué. La mise à jour du cœur de Drupal, elle, reste presque toujours sous votre responsabilité ou celle de votre prestataire de maintenance : personne ne l'applique à votre place sans que vous lanciez l'opération.
Mesures de mitigation en attendant le déploiement du correctif
Pour PHP2Shell, le PSA de Drupal est clair sur un point : il n'existe pas de contournement qui remplace la mise à jour de PHP. Pour SA-CORE-2026-014, l'avis documente en revanche une mitigation d'attente : désinstaller le module core Field UI (field_ui), ce qui protège le site le temps d'appliquer le correctif. Les sites qui utilisent Drupal Steward sont déjà protégés contre une partie des vecteurs d'attaque connus de cette faille, mais cette protection ne couvre pas tous les exploits possibles et ne dispense donc pas de mettre à jour le core.
Tester avant de passer en production
Une mise à jour de PHP peut casser du code qui dépendait d'un comportement spécifique à une ancienne version. Une mise à jour de Drupal core, elle, peut entrer en conflit avec un module contribué ou du code métier non maintenu. Avant de déployer en production, passez par un environnement de recette qui reproduit la configuration réelle du site : modules activés, thème, intégrations externes. Vérifiez en particulier les fonctionnalités qui touchent Field UI si vous appliquez SA-CORE-2026-014, puisque c'est le module directement concerné par le correctif.
Ce que cet épisode dit de la maintenance Drupal au quotidien
Deux failles critiques publiées à une semaine d'écart, suivies de deux fins de vie dans le même mois, ne sont pas un hasard malheureux. Ce sont deux calendriers de support indépendants, que PHP et Drupal font avancer chacun de son côté. Un site qui attend la prochaine alerte pour vérifier sa version de PHP et de Drupal découvre toujours la mauvaise nouvelle au pire moment. La maintenance qui fonctionne est celle qui suit ces deux calendriers en continu, avant qu'une CVE ne les rende urgents en même temps.
Si vous ne savez pas aujourd'hui avec certitude quelle version de PHP tourne derrière votre site Drupal, ni si votre cœur Drupal inclut déjà le correctif de SA-CORE-2026-014, c'est le signal qu'un diagnostic s'impose avant la prochaine alerte, pas après. Demander un diagnostic permet de faire ce point précis : versions exactes, dépendances à risque et ordre de mise à jour adapté à votre site.