En bref : après la mise à jour de PHP, vous devez redémarrer PHP-FPM et tous les autres services qui chargent PHP. De nouveaux fichiers sur le disque ne suffisent pas tant que d'anciens processus PHP tournent en mémoire. Ce n'est qu'après le redémarrage que le serveur travaille avec le code corrigé de PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou le backport de votre fournisseur.
Pourquoi vous devez redémarrer PHP-FPM
Une mise à jour de paquet remplace les fichiers sur le disque. Les processus déjà en cours ont toutefois déjà chargé l'ancien code du programme en mémoire et continuent de travailler avec. PHP-FPM, Apache avec mod_php ou LiteSpeed maintiennent souvent leurs workers en vie pendant des jours.
Pour PHP2Shell, c'est particulièrement important. La faille CVE-2026-109619 tient précisément à un état qui subsiste entre les requêtes dans le même worker. Un worker avec l'ancien code reste vulnérable, quelle que soit la version présente sur le disque. Selon php.net, tous les workers et processus doivent donc être redémarrés.
Certains gestionnaires de paquets redémarrent les services automatiquement lors de la mise à jour, d'autres non. Ne vous y fiez pas, mais vérifiez le résultat.
Une image typique du quotidien : la gestion des paquets signale « PHP mis à jour », la supervision n'affiche aucune erreur, le site web fonctionne. Pourtant, les anciens workers continuent de traiter chaque requête, car personne n'a redémarré le service. De l'extérieur, cet état est invisible. C'est pourquoi la vérification des heures de démarrage des processus fait partie de chaque mise à jour.
Quels services chargent PHP ?
| Mode d'exécution | Quoi redémarrer | Commande typique (noms variables selon la distribution) |
|---|---|---|
| PHP-FPM | chaque service FPM, pour chaque version installée | systemctl restart php8.3-fpm ou systemctl restart php-fpm |
| Apache avec mod_php | Apache | systemctl restart apache2 ou systemctl restart httpd |
| php-cgi | le serveur web appelant ou l'enveloppe FastCGI | selon la configuration |
| LiteSpeed | LiteSpeed et les processus lsphp | via l'administration de LiteSpeed ou son service |
| FrankenPHP | le service FrankenPHP ou le conteneur | systemctl restart frankenphp ou recréer le conteneur |
| Docker, Kubernetes | recréer les conteneurs à partir de la nouvelle image | voir Corriger PHP dans les conteneurs Docker |
Avec mod_php, la mise à jour concerne Apache lui-même, car PHP se trouve dans chaque processus Apache. Pourquoi ce mode d'exécution est particulièrement délicat, voir Pourquoi mod_php porte le risque le plus élevé. Pour LiteSpeed, vous trouverez des détails sur la page LiteSpeed et LSAPI.
Redémarrer PHP-FPM : les commandes
Trouvez d'abord tous les services PHP du serveur. Plesk, cPanel et d'autres interfaces apportent leurs propres services PHP avec leurs propres noms ; la liste les affiche aussi.
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
Redémarrez ensuite chaque service PHP trouvé, pas seulement le premier :
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm # si une seconde branche est installée
sudo systemctl restart apache2 # avec mod_php ; famille RHEL : httpd
Nous recommandons restart plutôt que reload. Avec un reload, le processus principal subsiste ; c'est prévu pour les modifications de configuration. Après une mise à jour de sécurité, vous voulez être sûr que chaque processus est neuf.
Si vous avez en plus mis en place des mesures transitoires comme session.upload_progress.enabled=0 ou des limites de mémoire fixes, celles-ci ne s'appliquent elles aussi qu'après le redémarrage. Un redémarrage règle les deux en une seule étape.
Vérifier qu'aucun ancien worker ne tourne plus
Comparez l'heure de démarrage des processus avec le moment de la mise à jour. Toutes les commandes sont en lecture seule.
ps -o pid,lstart,cmd -C php-fpm8.3 # sous RHEL : -C php-fpm
systemctl status php8.3-fpm # ligne « Active: … since … »
needrestart -r l # Debian/Ubuntu, si installé
Si un processus est plus ancien que la mise à jour, il n'a pas été pris en compte. Les causes fréquentes sont une seconde branche PHP oubliée, un service de pool propre issu d'un panneau d'hébergement ou un conteneur qui a seulement été redémarré au lieu d'être recréé à partir de la nouvelle image. Savoir si la bonne version tourne, la page Bien vérifier la version de PHP et l'état des correctifs le montre.
Documenter le redémarrage
Notez pour chaque serveur le moment de la mise à jour et celui du redémarrage. Cet instant sépare la période où le serveur était vulnérable de celle qui suit. Pour un examen ultérieur des traces, pour les assureurs et pour une éventuelle notification au titre du RGPD, c'est le repère le plus important. Conservez en outre les journaux du serveur à partir du 20 octobre, comme le recommande la presse spécialisée.
Sur les serveurs hébergeant de nombreux sites web, un petit tableau vaut la peine : serveur, service, version de PHP, version du paquet, heure du redémarrage et personne ayant redémarré. Les lacunes de couverture ressortent ainsi vite, par exemple un pool oublié ou un système de test que personne n'avait sur sa liste.
Comment PHP SOS aide-t-il concrètement ?
Dans le cadre du service de correctifs PHP, nous prenons en charge la mise à jour et le redémarrage comme un déroulement cohérent :
- Déterminer les services : nous trouvons tous les processus qui chargent PHP, y compris ceux issus de panneaux d'hébergement et de conteneurs.
- Redémarrer de façon contrôlée, en concertation avec vous, à un moment approprié et en tenant compte des commandes ou formulaires en cours.
- Revérifier qu'aucun processus n'est plus ancien que la mise à jour et que le site web répond normalement.
- Consigner : versions, états des paquets et heures de redémarrage pour chaque serveur.
Questions fréquentes
systemctl reload suffit-il à la place de restart ?
Pour PHP2Shell, nous recommandons restart. Un reload redémarre certes généralement les workers, mais le processus principal peut continuer de tourner. Avec restart, vous vous assurez qu'aucun processus avec l'ancien code ne subsiste. À la brève interruption s'oppose une preuve claire.
Dois-je redémarrer tout le serveur après la mise à jour de PHP ?
En règle générale non. Il suffit de redémarrer tous les services qui chargent PHP : PHP-FPM, Apache avec mod_php, LiteSpeed, FrankenPHP ou les conteneurs concernés. Redémarrer tout le serveur est la variante simple si vous ne savez pas avec certitude quels services utilisent PHP.
Mon hébergeur redémarre-t-il PHP automatiquement après la mise à jour ?
Cela dépend du fournisseur. Demandez précisément si tous les processus PHP ont été redémarrés après le correctif, et faites-vous-le confirmer par écrit.