Développement Web

Quelle version de PHP installer selon votre version de Drupal

La réponse tient en une règle : restez sur une branche PHP maintenue et acceptée par votre version de Drupal, au minimum au niveau du correctif du 21 octobre 2026. Voici la correspondance, établie à partir de la matrice de compatibilité PHP de Drupal et de l'avis de sécurité PHP.

Drupal 11 (11.3 et 11.4)

• PHP 8.3 : installer 8.3.36 ou plus. Branche en correctifs de sécurité uniquement, choix sûr pour un site en production.
• PHP 8.4 : installer 8.4.27 ou plus. Branche en support actif, notre recommandation par défaut sur Drupal 11.
• PHP 8.5 : installer 8.5.12 ou plus. Acceptée par Drupal 11.3 et 11.4, à réserver aux sites dont les modules contribués sont validés sur 8.5.
• PHP 8.2 et inférieur : sans objet, Drupal 11 exige PHP 8.3 au minimum.

Drupal 10 (10.6)

• PHP 8.3 : installer 8.3.36 ou plus. C'est la cible que nous recommandons, car c'est aussi le minimum de Drupal 11.
• PHP 8.4 : installer 8.4.27 ou plus. Possible, à condition que tous les modules contribués suivent.
• PHP 8.2 : installer 8.2.35. Corrigé aujourd'hui, mais la branche 8.2 sera en fin de vie le 31 décembre 2026.
• PHP 8.1 : aucune version officielle corrigée. C'est le cas délicat, détaillé ci-dessous.
• PHP 8.5 : non supporté par Drupal 10.

Drupal 10.5 et versions plus anciennes

Drupal 10.5 ne reçoit plus de correctifs de sécurité depuis le 17 juin 2026. Mettez d'abord à jour le core en 10.6, puis appliquez la règle ci-dessus. Un Drupal 7, 8 ou 9 tournant encore sur PHP 7.4 ou 8.0 cumule un core et un PHP sans support : la seule issue durable est une migration vers Drupal 11.

Ces numéros sont ceux du projet PHP. Si votre serveur utilise les paquets de sa distribution Linux (Debian, Ubuntu, RHEL et dérivés), le correctif peut être rétroporté dans un paquet qui affiche toujours un ancien numéro de version : c'est le changelog du paquet, et la mention des deux CVE, qui fait foi.

Drupal 10 en PHP 8.1 : pourquoi c'est le cas délicat

Oui, un site Drupal 10 en PHP 8.1 est vulnérable, et il n'existe aucune version officielle de PHP 8.1 corrigée. Les branches 7.4, 8.0 et 8.1 ne sont plus maintenues par le projet PHP. Vu la gravité des failles, l'équipe sécurité de PHP a tout de même publié des rétroportages minimaux, mais uniquement sous forme de code source sur GitHub, à compiler soi-même.

Il reste trois issues réalistes, par ordre de préférence :

• Passer en PHP 8.3.36, accepté par Drupal 10.6. C'est la meilleure option, car elle prépare la migration vers Drupal 11 qui exige PHP 8.3 au minimum : le travail de compatibilité (modules contribués, code personnalisé, composer.json) est fait une fois pour toutes.
• Installer un paquet PHP 8.1 rétroporté par votre distribution ou par un fournisseur de support étendu. Ubuntu, Debian LTS, RHEL et les dépôts tiers maintenus ont reçu les correctifs en avance. Vérifiez la mention des CVE-2026-109618 et CVE-2026-109619 dans le changelog du paquet installé.
• Compiler PHP 8.1 depuis les branches de rétroportage publiées sur GitHub. À réserver aux équipes qui savent maintenir un PHP compilé dans la durée.

Le passage de 8.1 à 8.3 n'est pas qu'un changement de paquet. Les points que nous vérifions systématiquement en TMA :

• La contrainte config.platform.php de composer.json, souvent figée à 8.1 et qui bloque la résolution des dépendances.
• Les modules contribués abandonnés ou figés sur une ancienne version, qui déclenchent des dépréciations voire des erreurs fatales en 8.3.
• Le code personnalisé : propriétés dynamiques (dépréciées depuis PHP 8.2), appels à des fonctions retirées.
• La version de PHP du CLI et du cron, à aligner sur celle du serveur web pour que Drush et les tâches planifiées tournent dans le même environnement.

# Vérifier quels paquets bloqueraient PHP 8.3 (à lancer depuis la racine du projet)
composer why-not php 8.3

# Simuler la résolution des dépendances avec la nouvelle plateforme
composer config platform.php 8.3.36
composer update --dry-run

Comment vérifier la version de PHP de votre site Drupal

Le piège le plus fréquent : vérifier la version de PHP dans le terminal et conclure que le site est à jour. Sur un même serveur cohabitent souvent plusieurs PHP, et le CLI n'est pas forcément celui qui sert vos pages.

La version servie par le web : le rapport d'état

Dans l'administration Drupal, ouvrez Rapports › Rapport d'état (/admin/reports/status). La ligne « PHP » affiche la version exécutée par le serveur web, c'est-à-dire celle qu'un attaquant atteint. C'est elle qui compte.

La version du CLI : Drush

# Version de PHP utilisée par Drush (le CLI), pas forcément celle de PHP-FPM
vendor/bin/drush php:eval 'echo PHP_VERSION, PHP_EOL;'

Si le rapport d'état affiche 8.3.30 et Drush 8.3.36, votre site n'est pas corrigé : le CLI a été mis à jour, pas le pool PHP-FPM ou le module Apache.

Sur le serveur : le paquet et son changelog

# Debian / Ubuntu : version et historique du paquet PHP-FPM installé
dpkg -l | grep -E 'php8\.[1-5]-(fpm|cli)|libapache2-mod-php'
apt changelog php8.3-fpm | grep -m5 -E 'CVE-2026-10961[89]'

# RHEL, AlmaLinux, Rocky Linux
rpm -q --changelog php-fpm | grep -m5 -E 'CVE-2026-10961[89]'

Si le changelog mentionne les deux CVE, le paquet est corrigé, quel que soit le numéro de version affiché. En hébergement mutualisé ou en PaaS, vous n'avez pas la main sur ce niveau : demandez à votre hébergeur une confirmation écrite que la version de PHP qui sert votre site intègre les correctifs, et à quelle date les workers ont été redémarrés.

Mettre à jour PHP et redémarrer tous les workers

Installer le paquet ne suffit pas. Un worker PHP-FPM ou un processus Apache démarré avant la mise à jour continue d'exécuter l'ancien binaire chargé en mémoire, potentiellement pendant des jours. Le redémarrage fait partie du correctif.

# Debian / Ubuntu avec PHP-FPM (adapter le numéro de branche)
sudo apt update && sudo apt install --only-upgrade 'php8.3-*'
sudo systemctl restart php8.3-fpm

# Apache avec mod_php : c'est Apache qui embarque PHP
sudo systemctl restart apache2   # httpd sur RHEL et dérivés

# Contrôle : tous les processus doivent avoir démarré après la mise à jour
ps -o pid,lstart,cmd -C php-fpm8.3

Quelques cas que l'on oublie :

• Plusieurs branches installées côte à côte (par exemple php8.1-fpm et php8.3-fpm) : chaque service doit être mis à jour et redémarré, y compris celui d'un ancien site que l'on croyait éteint.
• Docker : reconstruire l'image sur une image de base PHP corrigée puis redéployer ; mettre à jour le conteneur en place ne survit pas au prochain déploiement.
• FrankenPHP et LiteSpeed : PHP est embarqué dans le serveur, c'est le binaire du serveur qu'il faut mettre à jour. Voir notre retour sur Drupal 11 avec FrankenPHP et Docker.
• Après le redémarrage, revenir au rapport d'état Drupal : c'est la seule vérification qui prouve que la version servie a changé.

Ce que corrigent CVE-2026-109618 et CVE-2026-109619, et pourquoi mod_php est le plus exposé

Les deux failles, surnommées « PHP2Shell », se situent dans le moteur PHP lui-même, pas dans Drupal. Elles se déclenchent avant que la moindre ligne de Drupal ne s'exécute : aucun module de sécurité, aucun pare-feu applicatif côté Drupal ne peut les intercepter. Le projet PHP considère comme concernées toutes les installations qui servent des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed.

CVE-2026-109618 : un dépassement mémoire pendant l'initialisation de la requête

Quand PHP manque de mémoire, il interrompt brutalement la requête. Pendant l'analyse automatique du corps d'une requête (formulaires multipart, téléversements), certaines structures sont encore incomplètes à ce moment-là ; la phase de nettoyage les traite ensuite comme valides. Un attaquant peut provoquer ce dépassement avec une requête multipart forgée qui reste sous les limites apparentes, par exemple sans Content-Length exploitable ou avec un grand nombre d'en-têtes par partie. Détails dans l'avis GHSA de CVE-2026-109618.

CVE-2026-109619 : un état qui survit d'une requête à l'autre dans le même worker

Un worker PHP sert de nombreuses requêtes successives. Si une erreur fatale ou un dépassement de temps d'exécution interrompt une requête avant la remise à zéro de certains états globaux, ceux-ci pointent vers une mémoire déjà libérée. La requête suivante traitée par ce worker peut alors réutiliser ce pointeur. Les chemins confirmés passent par la progression de téléversement des sessions (session.upload_progress, activée par défaut) et, en PHP 8.5, par les traces d'erreurs fatales. Détails dans l'avis GHSA de CVE-2026-109619.

Pourquoi Apache avec mod_php est le cas le plus grave

Avec mod_php, PHP exécute la phase de fin de requête même quand l'initialisation a échoué. C'est exactement ce dont la première faille a besoin : l'avis indique une exécution de code validée par HTTP contre mod_php, avec les limites par défaut et des workers en mode prefork. PHP-FPM, lui, arrête le processus enfant quand l'initialisation échoue, ce qui ferme ce chemin précis, sans rendre FPM sûr pour autant. Beaucoup de VPS installés il y a plusieurs années avec un Apache « tout-en-un » tournent encore en mod_php : c'est la première configuration à corriger.

Côté exploitation, la publication a été avancée d'un jour après la fuite des identifiants de CVE. Plusieurs acteurs (Cloudflare, watchTowr, Amazon) signalent des tentatives d'attaque depuis le 21 octobre. Au 22 octobre, aucune des deux CVE ne figurait au catalogue KEV de la CISA, mais attendre une confirmation officielle n'est pas une stratégie sur une faille de ce niveau.

Drupal 11.4.11, 11.3.20 et 10.6.20 : pourquoi le .htaccess change le même jour

Le 21 octobre 2026, Drupal a aussi publié 11.4.11, 11.3.20 et 10.6.20. Ce ne sont pas des correctifs de sécurité, mais elles modifient le fichier .htaccess : la directive php_value assert.active 0, dépréciée depuis PHP 8.3, est remplacée par php_value zend.assertions 0.

Le lien avec les failles n'est pas écrit dans les notes de version Drupal, mais il est direct. L'avis de CVE-2026-109619 cite, parmi les déclencheurs possibles, les diagnostics émis par des réglages INI appliqués à chaque requête, notamment via php_value dans un .htaccess sous mod_php. Et l'avis PHP recommande de supprimer les réglages invalides ou dépréciés appliqués par requête. Un site Drupal servi en mod_php avec l'ancien .htaccess coche précisément cette case.

Le .htaccess fait partie des fichiers d'échafaudage : selon votre configuration drupal/core-composer-scaffold, il est réécrit automatiquement à la mise à jour du core, ou conservé tel quel si vous l'avez personnalisé. Vérifiez le résultat :

  <IfModule mod_php.c>
-   php_value assert.active                   0
+   php_value zend.assertions                 0
  </IfModule>

Profitez du passage dans php.ini pour régler les assertions au niveau du serveur. La valeur -1, recommandée par Drupal en production pour les performances, ne peut pas être définie depuis un .htaccess : elle doit figurer dans php.ini ou dans la configuration du pool, avec un redémarrage.

; php.ini de production (Drupal 10.6 / 11.x)
zend.assertions = -1

Si vous ne pouvez pas mettre à jour aujourd'hui : les atténuations officielles et leurs limites

L'avis du projet PHP liste des mesures qui réduisent certains chemins d'attaque, en précisant qu'elles ne rendent pas l'installation sûre. Elles servent à tenir quelques heures ou quelques jours, le temps de planifier la mise à jour, pas à la remplacer.

Contre CVE-2026-109619

• Désactiver session.upload_progress.enabled. Drupal n'utilise pas cette fonctionnalité pour ses propres téléversements ; vérifiez seulement qu'aucun module personnalisé ne s'appuie dessus. L'avis GHSA juge même prudent de la laisser désactivée après la mise à jour.
• En PHP 8.5 uniquement, désactiver fatal_error_backtraces.
• Supprimer les réglages INI dépréciés appliqués par requête, comme l'ancien assert.active du .htaccess Drupal. Masquer les messages avec display_errors ou error_reporting ne suffit pas.

Contre CVE-2026-109618

• Abaisser post_max_size (8M sans téléversement de fichiers, 32M sinon) et garder upload_max_filesize en dessous.
• Limiter au niveau du serveur web ou du proxy la taille des requêtes décodées, le nombre de champs, de parties multipart et d'en-têtes, y compris pour les requêtes sans Content-Length exploitable.
• Encadrer la mémoire par une limite de conteneur ou de cgroup, jamais par RLIMIT_AS ou RLIMIT_DATA, qui peuvent justement provoquer l'échec d'allocation vulnérable.
• L'avis mentionne aussi memory_limit=-1, imposé via php_admin_value. Sans limite de cgroup, une seule requête peut alors saturer la mémoire du serveur : ne l'appliquer qu'avec cette protection en place.

Où écrire ces réglages

Dans php.ini, dans le pool PHP-FPM ou dans la configuration Apache, c'est-à-dire un endroit lu avant l'analyse de la requête. Jamais dans un .user.ini ni via ini_set() dans settings.php : appliqués trop tard, ils ne protègent de rien. Puis redémarrer tous les workers.

; /etc/php/8.3/fpm/pool.d/www.conf (Debian / Ubuntu, adapter la branche)
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M
; PHP 8.5 uniquement
; php_admin_flag[fatal_error_backtraces] = off

Votre plan d'action cette semaine

• Relever la version de PHP dans le rapport d'état Drupal de chaque site, pas dans le terminal.
• Mettre à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou vers un paquet de distribution dont le changelog cite les deux CVE.
• Redémarrer tous les pools PHP-FPM et Apache, puis revérifier le rapport d'état.
• En mutualisé ou en PaaS, obtenir la confirmation écrite de l'hébergeur.
• Mettre à jour le core Drupal en 11.4.11, 11.3.20 ou 10.6.20 et contrôler le .htaccess.
• Pour un Drupal 10 en PHP 8.1 ou 8.2, planifier PHP 8.3 puis Drupal 11 avant le 9 décembre 2026.

Ces failles rappellent qu'un site Drupal à jour ne suffit pas si la couche en dessous ne l'est pas. Si personne ne sait aujourd'hui qui surveille PHP sur votre serveur, c'est précisément le rôle d'une maintenance applicative qui couvre le core, les modules et l'environnement d'exécution.

Découvrir notre offre de maintenance TMA Drupal · Préparer la migration vers Drupal 11 · Demander un diagnostic de votre serveur