En bref : pour la sécurité PHP de Drupal, après PHP2Shell, c'est surtout le serveur qui compte : la faille se trouve dans PHP, pas dans Drupal. Vérifiez l'état de PHP dans le rapport d'état et auprès de l'exploitant, redémarrez tous les processus PHP, puis contrôlez settings.php, le répertoire files et les droits des rôles.
Drupal et PHP2Shell : la situation
Drupal est souvent utilisé pour de grands sites, des portails et des organismes publics, fréquemment avec de nombreux rédacteurs et interfaces. Les failles PHP CVE-2026-109618 et CVE-2026-109619 permettent, selon l'équipe PHP, d'exécuter du code malveillant à distance sans authentification. Le niveau de maintenance de Drupal lui-même n'y change rien.
Drupal a sa propre équipe de sécurité, qui publie des avis sur le cœur et les modules. PHP2Shell n'en fait pas partie, car ce n'est pas une faille de Drupal. Qui ne suit que les avis de Drupal peut donc être passé à côté de l'alerte.
Dans les grands projets Drupal, la responsabilité se répartit souvent entre plusieurs acteurs : une agence entretient le code, un centre de calcul exploite les serveurs, la rédaction est dans la maison. Clarifiez par écrit qui applique la mise à jour de PHP, qui déclenche le redémarrage et qui vérifie si quelque chose s'est produit auparavant. Dans les configurations avec plusieurs serveurs web derrière un répartiteur de charge, chaque serveur doit être corrigé et redémarré, sinon une partie des requêtes reste sur l'ancien PHP.
Sécurité PHP de Drupal : vérifier la version et l'état du correctif
Sous Rapports > Rapport d'état, Drupal affiche la version de PHP avec laquelle le site fonctionne, ainsi que des avertissements sur la configuration. En ligne de commande, drush status donne la version du PHP CLI, avec lequel s'exécutent aussi les tâches cron et les déploiements. Les deux doivent être corrigés.
Les versions corrigées en amont sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les distributions et les hébergeurs appliquent parfois les correctifs sous forme de backport ; le numéro reste alors identique, et c'est l'état confirmé des paquets qui fait foi. Les versions de PHP prises en charge par votre version de Drupal se vérifient dans la configuration requise sur drupal.org. Après la mise à jour, le redémarrage en fait partie, comme décrit sous Redémarrer PHP-FPM et tous les workers.
Dossiers et fichiers qui comptent
| Emplacement | Contenu | Point de contrôle |
|---|---|---|
sites/default/settings.php |
Base de données, hash salt, trusted_host_patterns |
Date de modification, includes insérés |
sites/default/files/ |
uploads publics, images générées, CSS et JS | aucun fichier PHP, .htaccess présent |
| répertoire de fichiers privé | uploads protégés, souvent en dehors de la racine web | droits d'accès |
modules/contrib/, modules/custom/ |
Modules de drupal.org et développements spécifiques | modules modifiés ou inconnus |
themes/ |
Thèmes avec modèles Twig | JavaScript étranger |
vendor/ |
Dépendances Composer | composer audit |
Drupal crée dans le répertoire files un .htaccess qui empêche l'exécution de PHP. Il agit sous Apache, pas sous Nginx. Il y faut une règle propre :
location ~* ^/sites/.+/files/.+\.php$ {
deny all;
}
Contrôles sans danger avec les outils intégrés et Drush :
find sites/*/files -type f -name "*.php"
drush pm:list --status=enabled --type=module
composer audit
Comparez l'état du code sur le serveur avec votre dépôt Git. Dans les projets Drupal avec Composer, c'est le moyen le plus rapide de repérer des fichiers étrangers ou modifiés, car chaque écart doit pouvoir s'expliquer.
Rôles, droits et modules comme risque
La connexion se trouve sous /user/login, la zone d'administration sous /admin. Dans Drupal, ce ne sont pas seulement les comptes administrateur qui décident de la sécurité, mais les permissions individuelles. Des droits comme gérer les modules, les utilisateurs, les permissions ou des formats de texte avec HTML complet sont en pratique des droits d'administrateur. Vérifiez sous Personnes et Permissions quels rôles les possèdent et qui appartient à ces rôles.
Les modules contrib étendent fortement Drupal, mais apportent leur propre code. Les modules sans maintenance active et les anciens développements spécifiques sont souvent la raison pour laquelle une mise à niveau de PHP est repoussée. Plus sur les dépendances sous Vérifier les failles dans les dépendances Composer.
Ce qu'apporte une mise à jour de Drupal et ce qu'elle n'apporte pas
Une mise à jour du cœur ou d'un module comble des défauts de ce code et peut permettre d'utiliser des versions de PHP plus récentes. Elle ne corrige pas PHP, ne supprime pas de fichiers étrangers de sites/default/files, ne réinitialise pas de permissions et n'efface pas de comptes créés en cachette. Le cache peut lui aussi continuer à livrer des contenus manipulés jusqu'à ce qu'il soit vidé. En cas de soupçon, le hash salt et l'accès à la base de données doivent être renouvelés.
Dans les installations multisites, plusieurs sites partagent le même code, mais ont chacun sous sites/ leur propre settings.php et leur propre répertoire files. Contrôlez alors chaque site séparément. Une découverte dans un site concerne en général aussi tous les autres, en raison du code commun.
Comment PHP SOS aide-t-il concrètement ?
- Nous contrôlons le PHP web et le PHP CLI de votre serveur Drupal et faisons confirmer le correctif et le redémarrage.
- Nous sauvegardons les journaux et les données et comparons l'état du code avec votre dépôt ou les paquets d'origine.
- Nous contrôlons
settings.php, le répertoirefiles, les règles du serveur, les rôles et les permissions. - Sur demande, nous assurons le suivi régulier dans le contrat de maintenance de sécurité, afin que les mises à jour de PHP et de Drupal ne divergent plus.
Questions fréquentes
Une mise à jour de sécurité de Drupal aide-t-elle contre PHP2Shell ?
Non. Les mises à jour de Drupal comblent des défauts du cœur de Drupal et des modules. PHP2Shell se situe dans le PHP du serveur et exige une mise à jour de PHP ou un backport confirmé, ainsi que le redémarrage de tous les processus PHP.
Où Drupal affiche-t-il la version de PHP ?
Dans le rapport d'état, sous Rapports. Avec Drush, drush status affiche la version de PHP en ligne de commande. Les deux indications peuvent différer, et aucune ne permet de reconnaître un backport avec certitude.
Le .htaccess du dossier files protège-t-il aussi sous Nginx ?
Non. Le .htaccess créé par Drupal n'est interprété que par Apache. Sous Nginx, il vous faut une règle propre dans la configuration du serveur qui bloque les fichiers PHP dans le répertoire files.
Que signifie trusted_host_patterns ?
Ce réglage de settings.php définit sous quels noms d'hôte Drupal répond. Il protège contre les attaques via des indications d'hôte manipulées et a sa place dans chaque installation de production.