# Serveur Plesk : vérifier et corriger les versions de PHP

> Mise à jour PHP Plesk après PHP2Shell : vérifiez handlers, état des paquets et backports, redémarrez tous les services PHP-FPM et prouvez le correctif.

Source : https://phpsos.de/fr/server/plesk/  
État : 25/10/2026  
Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6

**En bref :** une mise à jour PHP sous Plesk n'est terminée que lorsque chaque version de PHP installée est dans un état corrigé, que tous les services PHP-FPM ont été redémarrés et que vous pouvez le démontrer par l'état des paquets et l'heure de démarrage des processus. Le numéro de version affiché dans le panneau ne suffit pas, car les backports le laissent souvent inchangé.

## Ce que PHP2Shell signifie sur les serveurs Plesk

PHP2Shell désigne deux failles critiques dans PHP lui-même (CVE-2026-109618 et CVE-2026-109619, chacune CVSS v4.0 9.2). Elles permettent à des attaquants d'exécuter du code sur le serveur sans authentification. Sont notamment concernés PHP-FPM et Apache avec mod_php, c'est-à-dire précisément les modes d'exécution que Plesk configure pour les sites web.

Le 21 octobre 2026, le projet PHP a publié les versions corrigées 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Pour PHP 8.1 et antérieur, il n'existe plus de mises à jour officielles. Les serveurs Plesk ont une particularité : plusieurs versions de PHP y tournent souvent côte à côte, en partie fournies par Plesk lui-même, en partie par le système d'exploitation. Chacune nécessite une vérification propre.

> **Important:**
> Une mise à jour dans le panneau remplace des fichiers sur le disque. Tant que d'anciens processus PHP tournent en mémoire, la faille reste ouverte. Sans redémarrage de tous les workers, le correctif n'est pas effectif.

## Mise à jour PHP Plesk : commencer par recenser l'existant

Avant de mettre quoi que ce soit à jour, dressez la liste de tous les handlers PHP et des domaines qui les utilisent. Vous pouvez le faire via le panneau (Outils et paramètres, Paramètres PHP) ou en ligne de commande. Les commandes suivantes ne modifient rien, elles se contentent de lire.

```bash
# Tous les handlers PHP enregistrés avec version et chemin
plesk bin php_handler --list

# Version de chaque version de PHP installée par Plesk (chemin à titre d'exemple)
for p in /opt/plesk/php/*/bin/php; do echo "$p"; "$p" -v | head -1; done
```

Notez pour chaque handler : la version, le mode d'exécution (FPM, FastCGI, module Apache) et le nombre de domaines. Un handler sans domaine n'est pas une raison de baisser la garde. Il peut être attribué plus tard ou tourner sur des sous-domaines de test.

## Vérifier l'état des paquets plutôt que l'affichage

Plesk affiche le numéro de version que PHP lui-même renvoie. Si Plesk ou la distribution livre la correction sous forme de backport, 8.2.34 peut continuer d'apparaître alors que la correction est incluse. À l'inverse, un numéro d'apparence récente peut tromper si un paquet n'a pas encore été mis à jour. Ce qui compte, ce sont l'état des paquets installés et la confirmation écrite du fournisseur.

```bash
# Debian/Ubuntu (noms de paquets à titre d'exemple)
dpkg -l | grep -E 'plesk-php|php[0-9.]+-(fpm|cli)'

# AlmaLinux/Rocky/RHEL (noms de paquets à titre d'exemple)
rpm -qa | grep -E 'plesk-php|^php' | sort
```

Comparez les versions des paquets avec les indications des journaux de modifications de Plesk et les avis de votre distribution. Si la correction de CVE-2026-109618 et CVE-2026-109619 n'y est pas documentée de façon explicite, interrogez le fournisseur. Vous trouverez un modèle sous [Demander à l'hébergeur l'état du correctif](https://phpsos.de/fr/ratgeber/hoster-patch-status-erfragen/).

## Installer la mise à jour et redémarrer tous les workers

La mise à jour proprement dite passe par l'installateur Plesk ou le gestionnaire de paquets du système. Vient ensuite l'étape qui manque le plus souvent : le redémarrage. Sous Plesk, chaque version de PHP a son propre service FPM. Redémarrez-les tous, pas seulement celui du domaine principal.

```bash
# Lister tous les services PHP-FPM (noms de services à titre d'exemple)
systemctl list-units --type=service | grep -i 'php.*fpm'

# Redémarrer chaque service, p. ex. :
systemctl restart plesk-php84-fpm

# Vérifier l'heure de démarrage des processus PHP en cours
ps -eo pid,lstart,cmd | grep -E 'php-fpm|php-cgi' | grep -v grep
```

Si un domaine tourne avec Apache et mod_php, redémarrez Apache complètement. Si l'heure de démarrage d'un processus PHP est antérieure à la mise à jour, il n'a pas encore été renouvelé. Pour en savoir plus sur cette étape, consultez [Redémarrer PHP-FPM et tous les workers](https://phpsos.de/fr/php2shell/php-fpm-neustart/).

## Protection transitoire tant que la mise à jour manque

Si aucun correctif n'est encore disponible pour une version, php.net recommande des mesures transitoires. Elles ne constituent pas une protection complète. Sous Plesk, définissez les valeurs que les applications ne doivent pas écraser sous la forme `php_admin_value` dans les directives FPM supplémentaires du domaine ou, pour tout le serveur, dans le php.ini de la version concernée.

```ini
; Exemple de directives PHP-FPM supplémentaires dans Plesk
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
```

Avec des envois de fichiers, php.net prévoit `post_max_size = 32M`, avec `upload_max_filesize` en dessous. Sur PHP 8.5, `fatal_error_backtraces=0` s'y ajoute. La limitation de mémoire via `memory_limit=-1` ne doit être utilisée qu'en combinaison avec une limite au niveau du conteneur ou du cgroup. Un nouveau redémarrage de tous les workers suit ensuite. Les détails figurent sous [Mesures immédiates sans correctif](https://phpsos.de/fr/php2shell/sofortmassnahmen-ohne-patch/). Le BSI (office fédéral allemand de la sécurité des technologies de l'information) recommande de déconnecter temporairement les serveurs web du réseau lorsque la mise à jour n'est pas possible immédiatement.

## Après le correctif : sauvegarder les journaux et rechercher des traces

Un correctif ferme la faille pour l'avenir. Il ne supprime pas les logiciels malveillants introduits auparavant et ne prouve pas que rien ne s'est produit. Conservez donc les journaux du serveur web à partir du 20 octobre 2026. Plesk les stocke pour chaque domaine dans le répertoire `logs` ; ne réduisez pas leur durée de conservation dans cette situation.

Soyez attentif aux fichiers PHP nouveaux ou modifiés dans les répertoires d'envoi, aux tâches planifiées inconnues et aux nouveaux comptes administrateur. Il n'existe pour l'instant aucun indicateur de compromission (IoC) publié et confirmé ; la détection repose sur l'analyse comportementale. Si vous constatez des anomalies, ne poursuivez pas seul : sauvegardez d'abord l'état du système.

## Comment PHP SOS aide-t-il concrètement ?

- Nous recensons tous les handlers PHP de votre serveur Plesk, associons les domaines et vérifions l'état réel des paquets pour chaque version.
- Dans le cadre de notre [service de correctifs PHP](https://phpsos.de/fr/leistungen/php-patch-service/), nous installons les mises à jour, redémarrons tous les services et consignons les heures de démarrage des processus comme justificatif.
- Là où un correctif manque, nous mettons en place les mesures transitoires selon php.net pour tout le serveur, sans possibilité de les écraser.
- Nous sauvegardons les journaux et recherchons des traces de compromission, en cas de constat avec la [réponse à incident](https://phpsos.de/fr/leistungen/incident-response/).
- Ensuite, nous durcissons le serveur de façon durable et supprimons les versions de PHP inutiles.


## Questions fréquentes

**Pourquoi Plesk affiche-t-il encore PHP 8.2.34 après la mise à jour ?**  
Les distributions et les fournisseurs appliquent parfois les corrections de sécurité sous forme de backport, sans modifier le numéro de version. Ce qui compte alors, c'est l'état des paquets et la confirmation du fournisseur. L'affichage seul ne prouve ni la présence ni l'absence d'un correctif.

**Suffit-il de cliquer sur Mettre à jour dans le panneau Plesk ?**  
La mise à jour dépose de nouveaux fichiers, mais les processus PHP en cours continuent de travailler en mémoire avec l'ancien code. Le nouvel état n'est actif qu'après le redémarrage de tous les services PHP-FPM et du serveur web. Vérifiez ensuite l'heure de démarrage des processus.

**Dois-je aussi corriger les versions de PHP qu'aucun domaine n'utilise ?**  
Oui, tant qu'elles restent installées. Un handler inutilisé peut être attribué par erreur plus tard ou être accessible via des environnements de test. Il vaut mieux désinstaller complètement les versions inutiles.

**Une mise à jour WordPress dans le Plesk Toolkit protège-t-elle contre PHP2Shell ?**  
Non. PHP2Shell concerne PHP lui-même, pas le CMS. Une mise à jour du CMS reste utile, mais ne comble pas cette faille.

## Sources

- [php.net : avis de sécurité](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net : versions prises en charge](https://www.php.net/supported-versions.php)
- [BSI : office fédéral allemand de la sécurité des technologies de l'information](https://www.bsi.bund.de/)