cPanel : vérifier le correctif PHP2Shell sur chaque PHP

Si votre serveur cPanel ou CloudLinux fait tourner plusieurs versions de PHP, voici comment confirmer que chacune contient le correctif PHP2Shell d’octobre 2026. Ce texte s’adresse aux administrateurs et aux agences qui gèrent WHM, le volet d’administration de serveur de cPanel. Vous avez lancé une mise à jour la semaine dernière, sans preuve qu’elle a touché toutes les versions. Les failles sont CVE-2026-109618 et CVE-2026-109619, deux bogues critiques qui peuvent permettre à un visiteur non authentifié d’exécuter du code sur un serveur web. Pour PHP 7.4, 8.0 et 8.1, le correctif est arrivé sous forme de rétroportage, une rustine appliquée à l’ancienne version sans changer son numéro. Un php -v qui affiche 7.4.33 ne vous apprend donc rien, dans un sens comme dans l’autre. La preuve, c’est le journal des modifications de chaque paquet, la liste datée des changements conservée dans le paquet installé, lue une fois par version.

Vous bâtirez la liste des versions installées, relierez chaque domaine à sa version, mettrez à jour ce qui manque, redémarrerez les processus et relancerez l’audit.

L’état des fournisseurs ci-dessous est au 26 octobre 2026. Le 21 octobre 2026, le projet PHP a publié 8.2.35, 8.3.36, 8.4.27 et 8.5.12 (archives des publications de php.net). La version 25.91 d’EasyApache 4 de cPanel, le même jour, a rétroporté le correctif dans ea-php74, ea-php80 et ea-php81 sans changement de version (billets EA-13613, EA-13612 et EA-13611). Elle a aussi fait passer ea-php82 à 8.2.35, ea-php83 à 8.3.36, ea-php84 à 8.4.27 et ea-php85 à 8.5.12 (journal des modifications d’EasyApache 4). La version 25.92 a reconstruit les paquets -meta correspondants pour que leur journal nomme aussi le rétroportage. Le billet de CloudLinux, mis à jour le 23 octobre, liste des paquets alt-php corrigés dans le dépôt stable pour 5.2 à 5.6, 7.0 à 7.4 et 8.0 à 8.5 sur CloudLinux 7, 8 et 9 (blogue de CloudLinux). Sur CloudLinux 10, seul alt-php52 se trouve dans le dépôt stable; les autres viennent du dépôt TuxCare Extended Lifecycle Support (ELS), une source de correctifs sur abonnement pour les logiciels en fin de vie. CloudLinux 6 est indiqué comme non confirmé.

Ce que vous allez accomplir

Une liste de toutes les versions de PHP installées sur le serveur, autant celles d’EasyApache 4 que celles de CloudLinux, avec un verdict corrigé ou non corrigé pour chacune.
Une preuve pour chaque verdict tirée du journal des modifications du paquet, pour qu’un ea-php74 rétroporté compte comme corrigé seulement quand il l’est.
Une carte des domaines et de la version que chacun utilise, y compris les comptes qui ont choisi leur propre version avec PHP Selector.
Des paquets mis à jour partout où le correctif manquait, et des processus Apache, PHP-FPM et LiteSpeed redémarrés.
Une vérification tenant sur un écran, que vous relancerez après le prochain avis de sécurité de PHP.

Prérequis

Un accès root en SSH, ou un accès root à WHM avec Terminal activé.
cPanel & WHM avec EasyApache 4, le système d’empaquetage de cPanel qui installe Apache et chaque version de PHP. Toutes les versions prises en charge de cPanel l’utilisent.
Un système d’exploitation à base de RPM, c’est-à-dire AlmaLinux, Rocky Linux ou CloudLinux. Sur cPanel pour Ubuntu, dpkg -l 'ea-php*' | grep '^ii' liste les mêmes noms de paquets, et vous comparez la version du paquet au journal des modifications à la main.
Sur CloudLinux 7, remplacez dnf par yum dans chaque commande.
Un instantané ou une sauvegarde récente, et une tolérance pour quelques requêtes perdues pendant le redémarrage de PHP-FPM.
Si une version se révèle non corrigée, les réglages temporaires de l’article atténuations PHP2Shell en attendant le correctif déjà en place.

Si le serveur n’a qu’une version de PHP venant de la distribution plutôt que de cPanel, suivez plutôt comment mettre à jour PHP sur un serveur Linux après un correctif de sécurité.

Comment ça fonctionne

EasyApache 4 installe chaque version de PHP comme un ensemble de paquets distinct sous /opt/cpanel/ea-phpNN/, avec ses propres binaires et son propre service PHP-FPM nommé ea-phpNN-php-fpm. CloudLinux ajoute une seconde famille, alt-php, installée sous /opt/alt/phpNN/ et offerte aux comptes par PHP Selector. PHP Selector donne à chaque utilisateur la version choisie à l’intérieur de CageFS, le système de fichiers virtuel par utilisateur que CloudLinux emploie pour isoler les comptes. Chaque domaine choisit sa version EasyApache dans le Gestionnaire MultiPHP. Un domaine laissé sur la valeur par défaut du serveur peut aussi être servi par l’alt-php que son propriétaire a sélectionné. « Le serveur est-il corrigé » cache donc deux questions. Chaque version installée contient-elle le correctif, et chaque domaine pointe-t-il vers une version qui le contient?

Deux colonnes comparant ea-php74 et ea-php83 après la mise à jour : php -v affiche encore 7.4.33 pour le rétroportage et ne prouve rien, alors que la ligne du journal rpm nommant CVE-2026-109618 est la preuve; pour ea-php83, la nouvelle version de paquet 8.3.36 est la preuve; aucune ligne CVE veut dire non corrigé

Le rétroportage déplace le piège. Pour ea-php82 et plus récent, le nouveau numéro de php.net (8.2.35, 8.3.36, 8.4.27, 8.5.12) est une preuve en soi. Pour ea-php74, ea-php80 et ea-php81, la version de PHP reste 7.4.33, 8.0.30 ou 8.1.34. Deux choses seulement bougent : le numéro de publication du paquet après la version, et une nouvelle entrée datée dans le journal des modifications qui nomme les deux CVE. Lire cette entrée, c’est l’audit. Les versions alt-php de CloudLinux suivent la même séparation. alt-php82 à alt-php85 portent les nouveaux numéros de php.net (8.2.35-1, 8.3.36-1, 8.4.27-1 et 8.5.12-1), tandis que les versions plus anciennes portent le rétroportage sous leur numéro existant.

Étape par étape

Listez chaque PHP installé par EasyApache 4. Demandez d’abord à WHM, parce qu’il sait quelles versions le Gestionnaire MultiPHP peut assigner :
```
whmapi1 php_get_installed_versions
```
Exemple de sortie :
```
---
data:
  versions:
    - ea-php74
    - ea-php81
    - ea-php83
    - ea-php84
metadata:
  command: php_get_installed_versions
  reason: OK
  result: 1
  version: 1
```
Listez ensuite les paquets avec leur version et leur numéro de publication complets, ce que vous comparerez plus tard :
```
rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' 'ea-php[0-9][0-9]-php-cli' | sort
```
Exemple de sortie :
```
ea-php74-php-cli-7.4.33-12.12.1.cpanel
ea-php81-php-cli-8.1.34-5.5.1.cpanel
ea-php83-php-cli-8.3.36-1.1.1.cpanel
ea-php84-php-cli-8.4.26-1.1.1.cpanel
```
Les deux listes devraient nommer les mêmes versions. Une version présente seulement dans la seconde liste est installée mais cachée du Gestionnaire MultiPHP, le plus souvent un paquet à moitié retiré. Corrigez cela d’abord dans WHM » Logiciel » EasyApache 4.
Listez les versions alt-php de CloudLinux, s’il y en a. Sautez cette étape sur AlmaLinux ou Rocky Linux sans CloudLinux.
```
rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' 'alt-php[0-9][0-9]' | sort
```
Exemple de sortie :
```
alt-php74-7.4.33-10.el8.cloudlinux
alt-php81-8.1.34-7.el8.cloudlinux
alt-php83-8.3.36-1.el8.cloudlinux
alt-php84-8.4.27-1.el8.cloudlinux
```
Tout compte dont le domaine est sur la valeur par défaut du serveur peut en sélectionner une, donc chacune a besoin de la même preuve.

Prouvez chaque version par son journal des modifications. Cette boucle imprime une ligne par version installée. Elle marque une version FIXED (changelog) quand le journal de son paquet nomme l’une des deux CVE, et CHECK autrement :

for p in $(rpm -qa --qf '%{NAME}\n' 'ea-php[0-9][0-9]-php-cli' 'alt-php[0-9][0-9]' | sort); do
  v=$(rpm -q --qf '%{VERSION}-%{RELEASE}' "$p")
  if rpm -q --changelog "$p" | grep -qE 'CVE-2026-(109618|109619)'; then
    s='FIXED (changelog)'
  else
    s='CHECK'
  fi
  printf '%-18s %-26s %s\n' "$p" "$v" "$s"
done

Exemple de sortie :

alt-php74          7.4.33-10.el8.cloudlinux   FIXED (changelog)
alt-php81          8.1.34-7.el8.cloudlinux    FIXED (changelog)
alt-php83          8.3.36-1.el8.cloudlinux    CHECK
alt-php84          8.4.27-1.el8.cloudlinux    CHECK
ea-php74-php-cli   7.4.33-12.12.1.cpanel      FIXED (changelog)
ea-php81-php-cli   8.1.34-5.5.1.cpanel        CHECK
ea-php83-php-cli   8.3.36-1.1.1.cpanel        CHECK
ea-php84-php-cli   8.4.26-1.1.1.cpanel        CHECK

Lisez les lignes CHECK à la lumière des numéros de php.net. Une ligne CHECK à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 ou plus récent est corrigée par son numéro de version; alt-php83, alt-php84 et ea-php83 ci-dessus sont donc en règle. Une ligne CHECK à tout autre numéro n’est pas corrigée. Dans l’exemple, ea-php81 à 8.1.34-5.5.1 n’a aucune ligne CVE, et ea-php84 à 8.4.26 est une publication en retard. Les deux ont besoin de l’étape 6. Pour voir l’entrée réelle du journal d’un paquet :

rpm -q --changelog ea-php74-php-cli | grep -B1 -E 'CVE-2026-(109618|109619)' | head -4

Exemple de sortie :

* Wed Oct 21 2026 cPanel Packaging <packaging@cpanel.net> - 7.4.33-12.12.1
- EA-13613: Backport fix for CVE-2026-109618 and CVE-2026-109619

La formulation varie entre les versions de cPanel et celles de CloudLinux. Ce qui compte, c’est la présence des deux numéros de CVE et une date au 21 octobre 2026 ou après.

Regardez la date de compilation, sans vous y arrêter. Le binaire de chaque version affiche la date à laquelle il a été compilé. Pour une version EasyApache :
```
/opt/cpanel/ea-php74/root/usr/bin/php -v
```
Exemple de sortie :
```
PHP 7.4.33 (cli) (built: Oct 21 2026 14:02:17) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
```
Pour une version alt-php, le binaire est /opt/alt/php74/usr/bin/php. Une date de compilation au 21 octobre 2026 ou après est cohérente avec un paquet corrigé, mais ce n’est qu’un indice. Une recompilation peut survenir pour une raison sans rapport, alors le journal de l’étape 3 reste la preuve.
Reliez chaque domaine à sa version. Une version corrigée n’aide personne tant qu’un domaine utilise encore une version non corrigée. WHM liste chaque hôte virtuel avec sa version résolue :
```
whmapi1 php_get_vhost_versions | grep -E '^ +(vhost|version): '
```
Exemple de sortie :
```
    version: ea-php84
    vhost: agence-nord.ca
    version: ea-php81
    vhost: boutique-lac.com
    version: ea-php83
    vhost: example.com
    version: ea-php83
    vhost: intranet.example.com
```
Chaque version listée ici doit avoir passé l’étape 3. Dans l’exemple, boutique-lac.com et agence-nord.ca sont exposés. La sortie complète contient aussi un bloc phpversion_source par domaine, qui vous dit si le domaine a fixé sa propre version ou hérité de la valeur par défaut du serveur. Un domaine sur la valeur par défaut du serveur est le genre que PHP Selector peut remplacer sur CloudLinux. Là, ouvrez WHM » CloudLinux Manager » PHP Selector pour voir le choix de chaque compte, ou interrogez un utilisateur depuis le terminal :
```
cloudlinux-selector get --json --interpreter php --user boutique
```
Sortie attendue : un document JSON qui nomme la version de PHP que cet utilisateur a sélectionnée. La valeur native veut dire que le compte est resté sur la version EasyApache du Gestionnaire MultiPHP. PHP Selector n’agit pas sur les domaines où le PHP-FPM de cPanel est activé, parce que ceux-là tournent dans le bassin ea-phpNN-php-fpm.
Mettez à jour les versions qui ne sont pas corrigées. Vérifiez ce que les dépôts offrent, puis mettez à jour les deux familles de paquets d’un coup :
```
dnf check-update 'ea-php*' 'alt-php*'
dnf -y update 'ea-php*' 'alt-php*'
```
dnf check-update liste chaque paquet qui a une version plus récente et retourne le code 100 quand il y en a au moins un. Une sortie vide avec le code 0 veut dire que votre miroir n’a rien de plus récent. La mise à jour se termine par Complete!. Si WHM » Configuration du serveur » Préférences de mise à jour règle les mises à jour de paquets du système à automatique, la mise à jour nocturne de cPanel lance cette commande pour vous. Il vous reste quand même le redémarrage et la revérification. Sur CloudLinux 10, les versions alt-php autres que 5.2 n’arrivent qu’une fois le dépôt TuxCare ELS activé sur le serveur. Au 28 octobre 2026, CloudLinux demande de garder ce dépôt activé aussi sur CloudLinux 7, 8 et 9, parce qu’il y devient également la seule source des paquets alt-php. Après une mise à jour d’alt-php, CageFS devrait prendre les nouveaux fichiers de lui-même. Si un compte voit encore l’ancienne date de compilation, forcez le rafraîchissement :
```
cagefsctl --force-update
```
Redémarrez chaque processus qui exécute PHP. Les mises à jour de paquets ne redémarrent pas de façon fiable les services qui les ont chargés. Un processus en marche garde l’ancien code tant qu’il ne redémarre pas. Redémarrez tous les bassins PHP-FPM d’EasyApache, puis Apache :
```
/scripts/restartsrv_apache_php_fpm
/scripts/restartsrv_httpd
```
Exemple de sortie (abrégé) :
```
Waiting for “apache_php_fpm” to restart ……finished.
Waiting for “httpd” to restart gracefully ……finished.
```
Le redémarrage d’Apache couvre le gestionnaire DSO, où PHP vit dans Apache, et le gestionnaire mod_lsapi que CloudLinux utilise pour alt-php, dont les processus lsphp meurent avec Apache. Les gestionnaires cgi et suphp lancent un nouveau processus PHP à chaque requête et n’ont pas besoin de redémarrage. Si LiteSpeed Web Server remplace Apache, redémarrez-le pour que ses processus lsphp se rechargent :
```
/usr/local/lsws/bin/lswsctrl restart
```
Déplacez les domaines hors des versions sans correctif. Si l’étape 3 montre encore une version non corrigée après la mise à jour, par exemple sur CloudLinux 10 sans ELS, repointez ses domaines vers une version corrigée. Préférez 8.3 ou 8.4, parce que PHP 8.2 atteint sa fin de vie le 31 décembre 2026. Depuis le terminal :
```
whmapi1 php_set_vhost_versions version=ea-php83 vhost=boutique-lac.com
```
Résultat attendu : result: 1 et reason: OK dans le bloc de métadonnées. Le même changement existe dans WHM » Logiciel » Gestionnaire MultiPHP; l’article Gestionnaire MultiPHP par compte couvre les tests qu’un saut de version exige. Quand beaucoup de comptes sont sur 7.4 ou 8.0, suivez le plan de migration de fin de vie de PHP à l’échelle du serveur. Une fois qu’aucun domaine n’utilise la version non corrigée, retirez-la dans WHM » Logiciel » EasyApache 4 pour que personne ne puisse la choisir de nouveau.

Validez que ça fonctionne

Relancez la boucle de l’étape 3. Chaque ligne doit afficher FIXED (changelog) ou porter un numéro corrigé par php.net. Conservez la sortie avec la date comme preuve.
Relancez la carte des domaines de l’étape 5. Aucun domaine ne doit se résoudre vers une version qui a échoué à la boucle, et sur CloudLinux aucun compte ne doit avoir sélectionné un alt-php non corrigé.

Confirmez que les processus ont redémarré après la mise à jour. Pour chaque service PHP-FPM :

systemctl list-units --plain --no-legend 'ea-php*php-fpm*' | awk '{print $1}' | xargs -n1 systemctl show -p Id -p ActiveEnterTimestamp

Exemple de sortie :

Id=ea-php74-php-fpm.service
ActiveEnterTimestamp=Mon 2026-10-26 09:14:02 EDT
Id=ea-php81-php-fpm.service
ActiveEnterTimestamp=Mon 2026-10-26 09:14:03 EDT
Id=ea-php83-php-fpm.service
ActiveEnterTimestamp=Mon 2026-10-26 09:14:03 EDT

Chaque ActiveEnterTimestamp doit être postérieur à l’exécution de dnf update. Vérifiez Apache de la même façon avec systemctl show -p ActiveEnterTimestamp httpd.

Confirmez le côté web sur un domaine par version avec une page phpinfo temporaire ou l’outil Santé du site de WordPress, comme dans comment vérifier quelle version de PHP votre site utilise vraiment. La PHP Version et la date de compilation doivent correspondre au paquet que vous avez prouvé, et la Server API doit être le gestionnaire que vous avez redémarré.
Confirmez que session.upload_progress.enabled affiche encore Off dans cette page phpinfo. L’avis de php.net du 23 octobre 2026 pour CVE-2026-115560 recommande de le garder désactivé jusqu’à la sortie d’une version corrigée, et au 26 octobre 2026 il n’en existe aucune.

Dépannage

La boucle affiche encore CHECK sur un ancien numéro après dnf update. Écartez d’abord le miroir avec dnf clean all && dnf makecache, puis relancez dnf check-update 'ea-php*'. Cherchez ensuite des lignes exclude= qui nomment ea-php ou alt-php dans /etc/dnf/dnf.conf ou /etc/yum.conf, et le dépôt EasyApache dans dnf repolist. Si rien de tout cela n’est en cause, le fournisseur n’a pas encore de version corrigée pour cette version, et l’étape 8 s’applique.
Un compte voit encore l’ancienne date de compilation d’alt-php depuis son propre terminal. CageFS lui sert une copie périmée. Lancez cagefsctl --force-update, puis demandez à l’utilisateur d’ouvrir une nouvelle session et de relancer php -v.
Un service PHP-FPM refuse de démarrer après la mise à jour. Lisez la raison avec journalctl -u ea-php84-php-fpm -n 50. Un fichier de bassin qui ne correspond plus à la disposition des comptes est la cause habituelle. Reconstruisez tous les fichiers de bassin avec /usr/local/cpanel/scripts/php_fpm_config --rebuild, puis redémarrez.
Un domaine sert encore l’ancien PHP après les redémarrages. Lancez ps -C lsphp -o pid,lstart,cmd pour repérer des processus lsphp démarrés avant la mise à jour. Sur LiteSpeed, lswsctrl restart règle le problème. Sur Apache, un systemctl restart httpd complet termine les enfants qu’un redémarrage gracieux a laissés finir de longues requêtes.

Quand ce n’est pas la bonne approche

Si vous louez un compte sur le serveur cPanel de quelqu’un d’autre, aucune de ces commandes ne s’exécute pour vous. Choisissez une version corrigée dans le Gestionnaire MultiPHP ou dans Select PHP Version de cPanel, et demandez à votre hébergeur de confirmer le journal des modifications du paquet. Si un fournisseur gère le serveur, demandez-lui la sortie de l’étape 3 avant de changer quoi que ce soit, pour ne pas entrer en conflit avec sa fenêtre de maintenance. Les ensembles de règles 8.83 à 8.88 du pare-feu applicatif Imunify360 réduisent l’exposition pendant le travail; au 26 octobre 2026, CloudLinux les présente comme une atténuation provisoire, pas comme un correctif. Si beaucoup de comptes utilisent encore PHP 7.4 ou 8.0, le rétroportage achète des semaines, pas des années. Les issues sont dans obtenir le correctif PHP2Shell sur PHP 7.4, 8.0 ou 8.1, et la réponse durable est le plan de migration de l’étape 8.

Si c’est le genre de travail que vous préféreriez ne plus jamais porter, c’est le quotidien d’Opérations Cloud — réservez une revue d’infrastructure.