# cPanel et WHM : sécuriser PHP

> Mise à jour PHP cPanel après PHP2Shell : vérifiez les paquets ea-php, redémarrez PHP-FPM et Apache, définissez les valeurs transitoires et prouvez le correctif.

Source : https://phpsos.de/fr/server/cpanel/  
É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 cPanel après PHP2Shell comprend trois étapes : amener tous les paquets ea-php et, le cas échéant, alt-php à un état corrigé, redémarrer complètement PHP-FPM et Apache, et documenter l'état des paquets. Les clients présents sur le serveur ne peuvent pas définir eux-mêmes les principales valeurs transitoires ; c'est à l'administrateur WHM de le faire.

## Situation de départ sur les serveurs cPanel

PHP2Shell regroupe les failles CVE-2026-109618 et CVE-2026-109619 dans PHP lui-même. Toutes deux permettent d'exécuter du code malveillant sans authentification et sont évaluées à CVSS v4.0 9.2. Sont concernés PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le 21 octobre 2026, le projet PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35.

cPanel ne fournit pas PHP sous la forme d'un paquet unique, mais via EasyApache 4, avec un jeu de paquets par version, par exemple `ea-php83` ou `ea-php84`. S'y ajoutent, sur certains serveurs, les paquets du système d'exploitation et, sur CloudLinux, les versions alt-php. Chaque source a son propre état. Vous n'obtenez une vue complète qu'en vérifiant les trois.

## Mise à jour PHP cPanel : vérifier l'inventaire et l'attribution

Commencez par un inventaire. Les commandes suivantes se contentent de lire et ne modifient rien. Les chemins et noms de paquets sont des exemples et peuvent varier selon l'installation.

```bash
# Versions de PHP installées selon l'API WHM
whmapi1 php_get_installed_versions

# Version de chaque installation ea-php
for p in /opt/cpanel/ea-php*/root/usr/bin/php; do echo "$p"; "$p" -v | head -1; done

# État des paquets (systèmes basés sur RPM, exemple)
rpm -qa | grep -E '^ea-php[0-9]+-php-(cli|fpm|common)' | sort
```

Dans le MultiPHP Manager, vous voyez quel domaine utilise quelle version et si PHP-FPM est activé. Relevez les versions installées mais attribuées à aucun domaine. Elles aussi doivent être mises à jour ou supprimées.

## Bien interpréter les backports

Comme chez d'autres fournisseurs, le numéro de version affiché n'est pas le seul critère. Si une correction est livrée sous forme de backport, le numéro peut rester inchangé. Vérifiez donc aussi le journal des modifications du paquet et les avis du fournisseur.

```bash
# Rechercher les numéros CVE dans le journal des modifications d'un paquet (exemple)
rpm -q --changelog ea-php84-php-cli | grep -iE 'CVE-2026-1096(18|19)'
```

L'absence d'entrée ne signifie pas automatiquement que la correction manque. Cela signifie en revanche qu'il vous faut une confirmation écrite avant de classer le serveur comme corrigé. Pour lire correctement les versions, consultez [Vérifier la version de PHP et l'état du correctif](https://phpsos.de/fr/php2shell/php-version-pruefen/).

## Mise à jour, redémarrage et contrôle

Vous installez la mise à jour dans WHM via la mise à jour du système ou avec le gestionnaire de paquets. Redémarrez ensuite tous les processus PHP. De nouveaux fichiers ne suffisent pas tant que d'anciens processus tournent en mémoire.

```bash
# Redémarrer les services PHP-FPM de toutes les versions (script cPanel)
/scripts/restartsrv_apache_php_fpm

# Redémarrer complètement Apache
/scripts/restartsrv_httpd

# Contrôler l'heure de démarrage des processus PHP
ps -eo pid,lstart,cmd | grep -E 'php-fpm|lsphp|php-cgi' | grep -v grep
```

Chaque processus PHP devrait avoir une heure de démarrage postérieure à la mise à jour. Si ce n'est pas le cas, arrêtez-le de façon ciblée via le service correspondant. Avec plusieurs serveurs, un court procès-verbal par machine, utilisable plus tard comme justificatif, vaut la peine.

> **Important:**
> Une mise à jour du CMS via des outils cPanel comme WP Toolkit ne comble pas la faille PHP. Elle est utile, mais ne remplace ni la mise à jour de PHP ni le redémarrage.

## Définir les valeurs transitoires de façon centralisée

Si une version n'est pas encore corrigée, php.net recommande des mesures transitoires qui n'offrent pas de protection complète. Sous cPanel, vous les définissez dans le MultiPHP INI Editor en mode administrateur ou directement dans le php.ini de la version ea-php concernée. Des valeurs dans le `.user.ini` des comptes clients ne suffisent pas pour `session.upload_progress.enabled`.

```ini
; php.ini global à la version concernée (exemple)
session.upload_progress.enabled = 0
post_max_size = 32M
upload_max_filesize = 24M
```

Sans fonction d'envoi de fichiers, php.net indique `post_max_size = 8M`. Sur PHP 8.5, `fatal_error_backtraces=0` s'y ajoute. Redémarrez ensuite à nouveau tous les workers. Une limite de mémoire se définit via les cgroups, par exemple avec les limites de CloudLinux, et non via `RLIMIT_AS` ou `RLIMIT_DATA`. Vous trouverez d'autres détails sous [Mesures immédiates sans correctif](https://phpsos.de/fr/php2shell/sofortmassnahmen-ohne-patch/).

## Responsabilité entre exploitant du serveur et titulaires de comptes

Sur un serveur cPanel comptant de nombreux comptes, l'administrateur WHM porte la responsabilité de PHP, des services et de la configuration globale. Les titulaires de comptes individuels sont responsables de leurs applications, extensions et identifiants. Informez-les du moment et de la manière dont le correctif a été appliqué, et recommandez-leur de rechercher des anomalies dans leurs applications. La situation du point de vue du client est décrite dans [Hébergement mutualisé](https://phpsos.de/fr/server/shared-hosting/).

Conservez les journaux à partir du 20 octobre 2026. Un correctif ne supprime pas les logiciels malveillants introduits auparavant.

Pour le justificatif, un simple procès-verbal par serveur suffit : date et heure de la mise à jour, liste des paquets ea-php et alt-php avec la version avant et après, liste des processus avec les heures de démarrage après le redémarrage et, le cas échéant, la confirmation du fournisseur des paquets au sujet des backports. Conservez ce procès-verbal en dehors du serveur. Il servira plus tard de preuve auprès des clients, des assureurs ou des auditeurs et facilitera la prochaine mise à jour d'urgence, puisque les étapes sont déjà décrites. Si vous exploitez plusieurs serveurs cPanel, il vaut la peine de regrouper les commandes de lecture de cette page dans un petit script qui s'exécute de la même façon sur toutes les machines et rassemble les résultats. Vous repérez ainsi d'un coup d'œil les écarts entre serveurs, par exemple une version de PHP oubliée.

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

- Nous inventorions les paquets ea-php, alt-php et système et associons chaque compte à sa version de PHP.
- Via notre [service de correctifs PHP](https://phpsos.de/fr/leistungen/php-patch-service/), nous effectuons la mise à jour, redémarrons tous les services et documentons l'état avec des listes de paquets et des heures de processus.
- Là où c'est nécessaire, nous définissons les valeurs transitoires pour tout le serveur, sans possibilité de les écraser.
- Nous examinons les comptes à la recherche de traces typiques d'une compromission et, en cas de constat, lançons la [suppression des logiciels malveillants](https://phpsos.de/fr/leistungen/malware-entfernung/).
- Ensuite, nous réduisons le nombre de versions de PHP et durcissons la configuration.


## Questions fréquentes

**Où voir dans WHM quel domaine utilise quelle version de PHP ?**  
Dans le MultiPHP Manager de WHM, vous voyez pour chaque domaine la version attribuée et si PHP-FPM est actif. Pour obtenir une liste complète, interrogez aussi le système en ligne de commande. Notez également les versions qui ne sont attribuées à aucun domaine.

**Un client cPanel peut-il définir lui-même les valeurs transitoires dans .user.ini ?**  
Pour session.upload_progress.enabled, php.net précise expressément que .user.ini et ini_set() ne suffisent pas. La valeur doit figurer dans le php.ini, le pool FPM ou la configuration du serveur. Seul l'administrateur du serveur peut le faire.

**Un redémarrage gracieux d'Apache suffit-il ?**  
Avec PHP-FPM, ce sont les services FPM eux-mêmes qui doivent redémarrer ; un rechargement d'Apache ne les renouvelle pas. Avec les handlers PHP basés sur Apache, un redémarrage complet est la voie sûre. Vérifiez ensuite l'heure de démarrage de tous les processus PHP.

**Qu'en est-il de CloudLinux et d'alt-php ?**  
Sur les serveurs CloudLinux, les sites tournent en partie avec leurs propres paquets alt-php plutôt qu'avec ea-php. Ils ont leur propre état de paquets et doivent être vérifiés et mis à jour séparément.

## 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/)