PHP2Shell : trouver, corriger et vérifier chaque serveur PHP

PHP2Shell désigne deux vulnérabilités critiques dans le moteur PHP lui-même, CVE-2026-109618 et CVE-2026-109619, publiées le 21 octobre 2026 avec un score CVSS de 9.2. Sur un environnement d’exécution non corrigé, un attaquant sans compte peut exécuter du code avec les droits du worker PHP ou lire la mémoire du processus, qui contient des mots de passe, des jetons de session, des clés d’API et des certificats. Votre code applicatif n’a pas besoin de contenir de bogue : selon les chercheurs, même une simple page « Hello World » sur une version de PHP concernée peut être exposée. La seule vraie correction est une version corrigée de PHP, suivie du redémarrage de chaque processus qui exécute PHP. Ce guide vous donne les commandes.

Quelles versions sont corrigées

PHP 8.1, 8.0 et 7.x sont en fin de vie et ne recevront aucun correctif. Si vous les utilisez encore, le correctif consiste à passer à une branche maintenue.

Les distributions Linux rétroportent souvent les correctifs de sécurité dans leurs propres paquets sans passer au numéro de version amont. Sur ces systèmes, la version seule ne suffit pas : cherchez les deux numéros de CVE dans le changelog du paquet (étape 2).

Étape 1 : trouver chaque environnement PHP

Commencez par l’inventaire, car c’est l’environnement dont personne ne se souvenait qui se fait attaquer. Sur chaque serveur :

php -v
systemctl list-units --type=service --all 'php*' 'apache2*' 'httpd*'
ls /usr/sbin/php-fpm* /usr/bin/php[0-9]* 2>/dev/null

La première ligne affiche la version CLI, la deuxième les pools PHP-FPM et les serveurs web en cours d’exécution, et la troisième chaque version de PHP installée en parallèle (une source fréquente d’environnements oubliés). Listez aussi les paquets installés :

dpkg -l 'php*' | grep '^ii'      # Debian, Ubuntu
rpm -qa 'php*' 'ea-php*'         # RHEL, AlmaLinux, Rocky, cPanel

Pour les conteneurs, vérifiez la version de PHP dans chaque image en cours d’exécution :

docker ps --format '{{.Names}}' | while read c; do printf '%s: ' "$c"; docker exec "$c" php -r 'echo PHP_VERSION, PHP_EOL;' 2>/dev/null || echo 'no php'; done

N’oubliez pas les serveurs de préproduction, de cron et de files d’attente, les agents de build et les offres d’hébergement managé. Pour une offre hébergée, demandez par écrit à l’hébergeur quel build de PHP vous utilisez et quand il a été corrigé.

Étape 2 : installer la version corrigée

Debian et Ubuntu (remplacez 8.3 par votre branche) :

sudo apt update
sudo apt install --only-upgrade 'php8.3*'
apt changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]'

RHEL, AlmaLinux, Rocky Linux :

sudo dnf upgrade 'php*'
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'

Serveurs cPanel avec les paquets EasyApache 4 :

sudo dnf upgrade 'ea-php*'      # older systems: sudo yum update 'ea-php*'

Alpine Linux (les noms de paquets incluent la branche, par exemple php83) :

apk update && apk upgrade 'php83*'

Images Docker : épinglez le tag corrigé dans le Dockerfile, par exemple FROM php:8.3.36-fpm, puis reconstruisez sans cache et remplacez les conteneurs en cours d’exécution :

docker build --pull --no-cache -t myapp:php2shell .
docker compose up -d --build --force-recreate

Si le grep sur le changelog n’affiche rien, votre distribution n’a pas encore publié le correctif. Continuez à vérifier, utilisez la version officielle de php.net là où vous compilez PHP vous-même, et appliquez en attendant les mesures provisoires ci-dessous.

Étape 3 : redémarrer tout ce qui a chargé l’ancien PHP

Un nouveau paquet ne change rien aux processus déjà en cours d’exécution. Redémarrez-les :

sudo systemctl restart php8.3-fpm     # Debian, Ubuntu (one per installed version)
sudo systemctl restart php-fpm        # RHEL family
sudo systemctl restart apache2        # Apache with mod_php (httpd on RHEL)
sudo supervisorctl restart all        # long-running workers under Supervisor
php artisan queue:restart             # Laravel queue workers

Sur Debian et Ubuntu, sudo needrestart -r l liste les services qui utilisent encore d’anciennes bibliothèques.

Étape 4 : vérifier

Vérifiez à nouveau chaque environnement, cette fois celui qu’utilise le serveur web, et pas seulement la CLI :

php-fpm8.3 -v                         # or: php-fpm -v
systemctl status php8.3-fpm | grep Active

La version doit être égale ou supérieure à la version corrigée (ou le changelog du paquet doit mentionner les deux CVE), et l’heure indiquée par « Active: since » doit être postérieure à la mise à jour. Sous WordPress, vous pouvez aussi lire la version dans Outils, Santé du site, Infos, Serveur. Ne mettez pas de page phpinfo() en ligne pour vérifier : elle divulgue exactement ce que cherchent les attaquants.

Quand la mise à jour doit attendre

Ces réglages recommandés par les chercheurs réduisent l’exposition pendant que vous préparez la mise à jour. Ce n’est pas une correction :

; php.ini
post_max_size = 8M                  ; as low as your uploads allow
max_input_nesting_level = 32        ; as low as your forms allow
session.upload_progress.enabled = 0
fatal_error_backtraces = 0          ; where your PHP version supports it

; PHP-FPM pool: recycle workers more often (costs performance)
pm.max_requests = 100

Les valeurs sont des exemples ; testez-les avec votre application. Le réglage memory_limit = -1 bloque certains chemins d’attaque, mais ne l’utilisez qu’avec une limite au niveau du système d’exploitation comme memory.max de cgroup v2, et ne remplacez jamais cette limite par RLIMIT_AS ou RLIMIT_DATA. Les règles WAF et CDN de votre fournisseur servent de solution de transition, pas de substitut à la mise à jour.

Rechercher des signes d’attaque

Il n’existe pas de règle de détection unique. Ces commandes font ressortir les signaux décrits par les chercheurs :

grep -E 'Allowed memory size of [0-9]+ bytes exhausted' /var/log/php*-fpm.log /var/log/apache2/error.log
grep -E 'exited on signal (6|11)' /var/log/php*-fpm.log
awk '$9 == 500' /var/log/nginx/access.log | wc -l

Les erreurs de limite mémoire après des requêtes multipart inhabituelles, les pics de réponses HTTP 500, les workers PHP qui plantent sur un signal et les cookies PHPSESSID anormalement volumineux dans les réponses méritent un examen plus attentif. Aucun de ces signes ne prouve une attaque, et leur absence ne prouve pas que vous n’avez pas été touché. Si vous les trouvez, conservez les journaux, appliquez le correctif et renouvelez les secrets présents dans la mémoire de PHP : mots de passe de base de données, clés applicatives et jetons d’API. Notre équipe de réponse à incident peut prendre l’investigation en charge, et notre service de sécurité managée peut surveiller vos serveurs après le correctif.

Par où commencer

1. Exécutez les commandes d’inventaire sur chaque serveur et chaque conteneur, et notez chaque version de PHP.
2. Mettez à jour avec votre gestionnaire de paquets ou reconstruisez vos images sur un tag corrigé.
3. Redémarrez PHP-FPM, Apache et chaque worker PHP.
4. Vérifiez la version et l’heure du redémarrage, et conservez la sortie comme preuve.
5. Cherchez avec grep les signes décrits plus haut dans vos journaux et renouvelez les secrets sur tout système qui les présente.

Détails : site d’information sur PHP2Shell, annonce de la PHP Foundation, Wiz Research.