Guide développeurs : corriger PHP2Shell

Sommaire

• Suis-je exposé ?
• Diagnostic en 9 étapes
• Lire le résultat
• Les pièges
• Debian / Ubuntu
• RHEL / Alma / Rocky
• Alpine
• Docker
• cPanel, Plesk, DirectAdmin
• Windows / IIS
• PHP ≤ 8.1
• Mesures provisoires
• Vérification
• Contrôle de compromission

Suis-je exposé ?

Toute installation PHP qui sert des requêtes web est concernée. Selon les avis officiels :

Configuration exploitée par la chaîne publique : session.upload_progress.enabled=On (valeur par défaut) et requêtes multipart acceptées. La faille se déclenche avant l'exécution de votre code : la qualité de l'application n'y change rien.

Diagnostic en 9 étapes

1. Quel système ?

cat /etc/os-release

Indique quelle section de mise à jour suivre (Debian/Ubuntu, RHEL, Alpine…).

2. Quelles installations de PHP existent ?

ls -d /usr/bin/php /usr/bin/php[0-9]* /usr/sbin/php-fpm* /opt/remi/php* /opt/cpanel/ea-php* /opt/plesk/php/* /opt/alt/php* 2>/dev/null

Chaque ligne est une installation à vérifier et à mettre à jour, même si le site ne l'utilise pas.

3. Quelle version pour chacune ?

php -v | head -1
for b in /usr/sbin/php-fpm* /opt/remi/php*/root/usr/sbin/php-fpm /opt/cpanel/ea-php*/root/usr/sbin/php-fpm; do [ -x "$b" ] && echo "$b : $("$b" -v | head -1)"; done

Les binaires FPM sont dans /usr/sbin, absent du PATH d'un utilisateur non-root sur Debian : d'où les chemins complets. php -v n'affiche pas toujours le suffixe de distribution (Ubuntu 22.04 l'affiche ; Debian 12, Ubuntu 24.04 et RHEL non) : la version exacte du paquet se lit à l'étape 4.

4. D'où viennent les paquets ?

dpkg -l | grep -E '^ii +(php|libapache2-mod-php)'     # Debian / Ubuntu
rpm -qa | grep -iE '^(php|ea-php|alt-php)'            # RHEL, cPanel, CloudLinux
apt-cache policy php8.2-common | grep -A1 '^ \*\*\*'   # dépôt d'origine de la version installée (adaptez la version)

+deb.sury.org = dépôt Sury / ondrej ; ~deb12u, ubuntu, .el9 = paquets de la distribution, qui peuvent contenir un correctif rétroporté.

5. Le correctif est-il dans le paquet ?

zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php*-common/changelog.Debian.gz           # Debian / Ubuntu / Sury
rpm -qa '*php*-common' | xargs -r rpm -q --changelog | grep -E 'CVE-2026-10961[89]'     # RHEL / Remi / cPanel

Une ligne affichée = correctif présent. Rien affiché : regardez le numéro de version. S'il est égal ou supérieur à la version corrigée, c'est corrigé (certains dépôts ne citent pas les CVE). Dans les images Docker Debian / Ubuntu, /usr/share/doc est vidé : ce contrôle n'y marche pas, fiez-vous à la version.

6. Quel PHP sert vraiment le site ?

ls /etc/apache2/mods-enabled/ 2>/dev/null | grep php                              # mod_php : quelle version (httpd -M sur RHEL)
grep -RhvE '^\s*#' /etc/apache2/conf-enabled/ /etc/apache2/sites-enabled/ /etc/httpd/conf.d/ 2>/dev/null | grep -oE 'proxy:unix:[^|"]+' | sort | uniq -c  # Apache → socket FPM
sudo nginx -T 2>/dev/null | grep -v '^\s*#' | grep -oE '(server_name|fastcgi_pass)[^;]+'  # nginx : site → socket
systemctl list-units --type=service --all '*php*fpm*'                               # services FPM

Le socket (ex. php8.2-fpm.sock) indique la version utilisée par chaque site. nginx -T affiche toute la configuration chargée ; le grep -v en retire les lignes commentées. Pour confirmer en HTTP, voir Vérification.

7. La mesure provisoire est-elle active côté FPM ?

/usr/sbin/php-fpm8.2 -i | grep -i 'upload_progress.enabled'      # RHEL : /usr/sbin/php-fpm -i ; Remi : /opt/remi/php82/root/usr/sbin/php-fpm -i ; cPanel : /opt/cpanel/ea-php82/root/usr/sbin/php-fpm -i
grep -r upload_progress /etc/php/*/fpm/pool.d/ /etc/php-fpm.d/ /etc/opt/remi/php*/php-fpm.d/ /opt/cpanel/ea-php*/root/etc/php-fpm.d/ 2>/dev/null

Lit le php.ini de FPM (pas celui du CLI), puis les réglages des pools. Avec mod_php, seule la vérification en HTTP fait foi.

8. Des processus tournent-ils encore sur l'ancien code ?

sudo grep -l 'php.*(deleted)' /proc/[0-9]*/maps 2>/dev/null | cut -d/ -f3 | while read p; do echo "$p $(tr '\0' ' ' < /proc/$p/cmdline)"; done   # partout, Alpine compris
sudo needrestart -b              # Debian / Ubuntu (absent par défaut sur Debian : sudo apt install needrestart)
sudo dnf needs-restarting -s     # RHEL et dérivés

La première commande liste les processus qui utilisent encore des fichiers PHP remplacés par la mise à jour. Rien affiché = rien à redémarrer. Si php-fpm, apache2 ou httpd apparaît : redémarrez-le.

9. Et dans les conteneurs ?

for c in $(docker ps --format '{{.Names}}'); do echo "== $c"; docker exec "$c" php -v 2>&1 | grep -m1 '^PHP '; done

Un bloc par conteneur ; une version s'affiche s'il contient PHP.

Sur plusieurs serveurs

for h in web1 web2 web3; do echo "== $h"; ssh "$h" 'php -v | head -1; ls -d /usr/sbin/php-fpm* 2>/dev/null'; done
ansible all -m shell -a 'php -v | head -1'

Lire le résultat

Appliquez le tableau à chaque installation trouvée à l'étape 2 (CLI, FPM, mod_php, conteneurs), et retenez la première ligne qui correspond. La première ligne passe avant les autres : un processus qui tourne sur l'ancien code expose le serveur, quelle que soit la version installée.

À part, l'étape 7 : upload_progress.enabled à On (ou 1) veut dire que la mesure provisoire n'est pas active. C'est normal une fois PHP corrigé ; sinon, voir les mesures provisoires.

Les pièges

Debian / Ubuntu (paquets de la distribution ou dépôt Sury / ondrej)

# État des lieux
sudo apt update
dpkg -l | grep -E '^ii +(php|libapache2-mod-php)'
apt list --upgradable 2>/dev/null | grep -i php

apt-cache policy libapache2-mod-php8.1 php8.1-common | grep -E '^\S|Installed|Candidate'

# 1. Mise à jour des paquets PHP versionnés installés (cli, fpm, mod_php, extensions…)
#    Le motif écarte phpmyadmin et les bibliothèques php-*, qui ne sont pas concernées
sudo apt install --only-upgrade $(dpkg -l | awk '/^ii +(php[0-9.]+-|libapache2-mod-php)/ {print $2}')

Ubuntu 22.04 et plus : après apt, needrestart affiche une liste de services à redémarrer, déjà cochés. Valider redémarre tout ce qui est coché. Décochez PHP-FPM si vous préférez le recharger version par version (étape 3).

# 2. Le correctif est-il dans les paquets ?
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php*-common/changelog.Debian.gz

# 3. Rechargement de PHP-FPM, une version à la fois (évite de couper tous les sites en même temps)
#    À répéter pour chaque version installée (8.2, 8.3…)
sudo php-fpm8.2 -t && sudo systemctl reload php8.2-fpm

# 4. Seulement si mod_php (étape 6 du diagnostic)
sudo systemctl restart apache2

Puis l'étape 8 du diagnostic pour vérifier qu'aucun processus ne tourne sur l'ancien code.

• Dépôt Sury / ondrej : le changelog cite en général les CVE ; à défaut, le numéro de version doit être au moins égal à la version corrigée de la branche.
• PHP 8.1 sur Ubuntu 22.04 (ou toute branche fournie par la distribution) : la règle « 8.1 = migrer » ne s'applique pas tout de suite, car la distribution maintient sa propre version. Consultez son avis de sécurité (USN pour Ubuntu, DSA/DLA pour Debian) et vérifiez le changelog.

RHEL / AlmaLinux / Rocky / Fedora

rpm -qa | grep -i php
sudo dnf upgrade --refresh 'php*'

# Le correctif est-il dans les paquets ?
rpm -qa '*php*-common' | xargs -r rpm -q --changelog | grep -E 'CVE-2026-10961[89]'

# Rechargement de PHP-FPM, une version à la fois
sudo php-fpm -t && sudo systemctl reload php-fpm
sudo systemctl reload php82-php-fpm   # Remi : un service par version (php82-php-fpm, php83-php-fpm…)
sudo systemctl restart httpd          # si mod_php

# Reste-t-il des processus sur l'ancien code ?
sudo dnf needs-restarting -s

Paquets Remi (php82-php-*, /opt/remi/...) : voir le piège n°4.

Alpine

Images Docker officielles php:*-alpine : cette section ne s'applique pas. PHP y est compilé dans /usr/local, apk upgrade ne le met pas à jour : voir la section Docker. Ce qui suit concerne les paquets php83, php84… d'Alpine.

apk info -v | grep -E '^php'
apk update && apk upgrade
php -v   # puis redémarrer le service php-fpm (rc-service php-fpm83 restart, par ex.)

Si php -v reste sous la version corrigée après apk upgrade, votre branche Alpine ne reçoit plus ce correctif (c'est le cas de 3.20, bloquée en 8.3.15) : passez à une branche maintenue.

Docker (image officielle php)

# 1. Fixez un tag au moins égal à la version corrigée (exemple)
#    FROM php:8.3.36-fpm   (vérifiez sur Docker Hub que le tag est publié)

# 2. AVANT de recréer : gardez une trace des fichiers modifiés dans les conteneurs
#    (le contrôle de compromission en aura besoin, la recréation les efface)
for c in $(docker compose ps --format '{{.Name}}'); do echo "== $c"; docker diff "$c"; done > docker-diff-avant-maj.txt

# 3. Récupérez les images et reconstruisez, puis recréez seulement le service PHP
#    (remplacez app par le nom de votre service PHP dans compose.yaml)
docker compose pull --ignore-buildable
docker compose build --pull --no-cache app
docker compose up -d --force-recreate app

# 4. Vérifiez DANS le conteneur
docker compose exec app php -v
docker compose exec app php-fpm -i | grep upload_progress.enabled

• Images dérivées (WordPress, Drupal…) : vérifiez qu'une nouvelle version de l'image est publiée, puis recréez les conteneurs. Les images gratuites Bitnami ne sont plus mises à jour depuis 2025 : vérifiez d'où viennent les vôtres.
• CI : reconstruisez avec --pull et sans cache, sinon l'ancienne couche PHP est réutilisée. Faites le tour des registres internes.

Kubernetes

# Quelle version de PHP tourne dans chaque pod ? (le nom de l'image ne contient pas toujours « php » ;
# kubectl exec interroge le premier conteneur du pod)
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{"\n"}{end}' \
  | while read ns p; do echo "$ns/$p : $(kubectl exec -n "$ns" "$p" -- php -v 2>/dev/null | head -1)"; done

# Déployez l'image corrigée en la référençant par digest : avec un tag réutilisé,
# les nœuds peuvent relancer l'ancienne image depuis leur cache
kubectl set image deployment/<nom> <conteneur>=<registre>/<image>@sha256:<digest> -n <namespace>
kubectl rollout status deployment/<nom> -n <namespace>

Même chose pour les StatefulSets, DaemonSets et CronJobs (kubectl set image statefulset/<nom> …).

cPanel / WHM, Plesk, DirectAdmin

cPanel / WHM (EasyApache 4)

rpm -qa | grep -E '^ea-php'            # (Ubuntu : dpkg -l | grep ea-php)
sudo dnf upgrade 'ea-php*'              # ou yum / apt selon l'OS
for b in /opt/cpanel/ea-php*/root/usr/bin/php; do echo "$b"; "$b" -v | head -1; done
sudo /scripts/restartsrv_apache_php_fpm
sudo /scripts/restartsrv_httpd

CloudLinux (PHP Selector / alt-php) : mettez aussi à jour sudo yum update 'alt-php*', car chaque compte peut utiliser sa propre version.

Plesk

Outils et paramètres → Mises à jour, ou en ligne de commande :

sudo plesk installer --select-release-current --upgrade-installed-components
for b in /opt/plesk/php/*/bin/php; do echo "$b"; "$b" -v | head -1; done

DirectAdmin (CustomBuild)

cd /usr/local/directadmin/custombuild
./build update
./build versions   # la version corrigée est-elle proposée ?
./build php
./build versions   # contrôle après compilation

Windows / IIS

1. Téléchargez la version corrigée sur windows.php.net (même variante NTS/TS et même architecture).
2. Arrêtez le serveur web avant de remplacer les fichiers (sinon php-cgi.exe garde les DLL verrouillées et vous obtenez un mélange d'ancienne et de nouvelle version) : iisreset /stop (ou arrêt du service Apache).
3. Sauvegardez le dossier PHP actuel et votre php.ini, remplacez les fichiers, gardez votre php.ini.
4. Vérifiez que le Visual C++ Redistributable requis par la nouvelle version est installé, et que les mappages de gestionnaires IIS pointent vers le bon dossier.
5. Redémarrez : iisreset /start.

PHP 8.1, 8.0, 7.4 et plus ancien

• Ces branches ne sont plus maintenues par PHP. L'équipe de sécurité a publié des correctifs minimaux sous forme de code source pour 7.4, 8.0 et 8.1, à compiler vous-même.
• Votre distribution ou un fournisseur de support étendu (Debian ELTS, TuxCare, Zend…) peut proposer un paquet corrigé : renseignez-vous auprès de lui.
• À moyen terme : migrez vers 8.2 au minimum. Vérifiez d'abord la compatibilité (PHPCompatibility, Rector, journal des erreurs en préproduction).
• Avant 7.4 : aucun correctif. Le centre de cybersécurité britannique (NCSC) recommande de mettre hors ligne tout système qu'on ne peut pas corriger rapidement.

Mesures provisoires (si vous ne pouvez pas mettre à jour tout de suite)

; Pool PHP-FPM, par ex. /etc/php/8.2/fpm/pool.d/www.conf (à répéter pour chaque pool)

; CVE-2026-109619 : chemin des sessions
php_admin_flag[session.upload_progress.enabled] = off

; CVE-2026-109619 : PHP 8.5 uniquement
php_admin_flag[fatal_error_backtraces] = off

; CVE-2026-109618 : mitigation principale (retire la protection contre l'épuisement mémoire)
php_admin_value[memory_limit] = -1

; Casse la condition « même worker » (coûteux en performances)
pm.max_requests = 1

Avec mod_php : mêmes directives sous la forme php_admin_flag session.upload_progress.enabled off dans la configuration Apache (pas dans .htaccess).

Compensez memory_limit = -1 par une limite au niveau du système, sinon une seule requête peut épuiser la mémoire et faire tuer d'autres services (base de données comprise). N'utilisez pas RLIMIT_AS / RLIMIT_DATA. Posez plutôt une limite systemd, avec OOMPolicy=continue : sans cette ligne, systemd arrête tout le service dès qu'un worker est tué, et tous les sites de cette version tombent.

sudo systemctl edit php8.2-fpm.service   # adaptez le nom du service

Dans l'éditeur qui s'ouvre, ajoutez ces lignes, puis enregistrez :

[Service]
MemoryMax=2G
MemorySwapMax=0
OOMPolicy=continue

MemorySwapMax=0 : sans elle, sur un serveur avec swap, la requête part en swap au lieu d'être coupée.

sudo systemctl restart php8.2-fpm
systemctl show php8.2-fpm -p MemoryMax -p MemorySwapMax -p OOMPolicy   # contrôle

OOMPolicy demande systemd 243 ou plus récent (systemctl --version). Retirez ces lignes avec la même commande systemctl edit une fois PHP corrigé. En conteneur, c'est la limite mémoire du conteneur qui joue ce rôle : un dépassement fait redémarrer tout le conteneur.

Autres mesures citées par les avis :

• Garder post_max_size bas et limiter la taille des requêtes au niveau du frontal (nginx, proxy, WAF).
• Réduire max_input_nesting_level et le nombre de variables et de parties multipart.
• Si l'application n'utilise pas de formulaires multipart (envoi de fichiers), bloquer ces requêtes avant PHP. Exemple nginx, dans le bloc location ~ \.php$ :

  client_max_body_size 1m;
  if ($http_content_type ~* "multipart/form-data") { return 403; }

• Ne pas laisser le frontal transmettre PHP_VALUE / PHP_ADMIN_VALUE à FPM.
• Cloudflare a déployé des règles WAF pour les vecteurs connus. Ça aide, mais ça ne remplace pas la mise à jour.

Vérification

Contrôlez la version réellement servie. Créez un fichier temporaire au nom imprévisible dans la racine web du site. D'abord, indiquez cette racine (modifiez le chemin avant de copier) :

DOCROOT=/var/www/monsite/public   # racine web du site (dossier public/ pour Laravel / Symfony)

f="v-$(cat /proc/sys/kernel/random/uuid).php"
echo '<?php header("Content-Type: text/plain"); echo PHP_VERSION, " ", PHP_SAPI, " upload_progress=", ini_get("session.upload_progress.enabled") ? "On" : "Off";' \
  | sudo tee "$DOCROOT/$f" >/dev/null
echo "Ouvrez : https://votre-site/$f"

Notez le résultat, puis supprimez le fichier depuis le même terminal (la variable $f n'existe que là) :

sudo rm -- "$DOCROOT/$f"

Laravel / Symfony avec nginx (seul index.php est servi) ou plusieurs pools FPM : interrogez chaque socket directement, sans rien déposer dans le site. Le fichier de test est placé dans /dev/shm, visible par FPM même avec PrivateTmp (RHEL). Un open_basedir peut toutefois le bloquer.

sudo apt install libfcgi-bin   # fournit cgi-fcgi (RHEL : dnf install fcgi, dépôt EPEL)
echo '<?php echo PHP_VERSION, " upload_progress=", ini_get("session.upload_progress.enabled") ? "On" : "Off", "\n";' | sudo tee /dev/shm/v.php >/dev/null
for s in /run/php/*.sock /run/php-fpm/*.sock /var/opt/remi/php*/run/php-fpm/*.sock /opt/cpanel/ea-php*/root/usr/var/run/php-fpm/*.sock; do [ -S "$s" ] && [ ! -L "$s" ] && echo "$s : $(sudo SCRIPT_FILENAME=/dev/shm/v.php REQUEST_METHOD=GET cgi-fcgi -bind -connect "$s" | tail -1)"; done
sudo rm /dev/shm/v.php

Enfin, l'étape 8 du diagnostic confirme qu'aucun processus ne tourne encore sur l'ancien code.

Contrôle de compromission

Aucun indicateur de compromission officiel n'a été publié à ce jour. Voici des vérifications classiques. Par prudence, remontez jusqu'au 15 octobre :

Alpine : installez d'abord findutils (sudo apk add findutils). Le find de BusyBox ne connaît pas -newerct, et comme les erreurs sont masquées, il ne trouverait rien sans le dire.

# Fichiers PHP créés ou modifiés depuis le 15/10 (ctime : ne peut pas être falsifié avec touch)
# Les caches de templates (ex. storage/framework/views) sont exclus : ils changent en permanence
sudo find /var/www /home /srv -type f -name '*.php' -newerct '2026-10-15' \
  -not -path '*/storage/framework/*' -not -path '*/var/cache/*' 2>/dev/null > ~/php-modifies.txt
wc -l ~/php-modifies.txt

# Fichiers PHP dans les dossiers d'upload, et fichiers suspects dans /tmp et /dev/shm
sudo find /var/www /home /srv -type f -name '*.php*' -path '*upload*' 2>/dev/null
sudo find /tmp /var/tmp /dev/shm -type f -newerct '2026-10-15' 2>/dev/null

# Rafales d'erreurs fatales mémoire (la faille repose sur des erreurs fatales / OOM), journaux archivés compris
# (sudo sh -c : les jokers doivent être développés par root, /var/log/httpd n'est pas lisible sinon)
sudo sh -c "zgrep -h 'Allowed memory size' /var/log/php*-fpm.log* /var/log/php-fpm/* /var/log/apache2/error.log* \
  /var/log/httpd/error_log* /var/log/nginx/error.log* /etc/apache2/logs/error_log* \
  /var/opt/remi/php*/log/php-fpm/* /opt/cpanel/ea-php*/root/usr/var/log/php-fpm/* 2>/dev/null" | tail -50
# (avec nginx + FPM, ces erreurs apparaissent aussi sous la forme « FastCGI sent in stderr » ;
#  sur cPanel, chaque site peut aussi avoir son propre fichier error_log)

# Tâches planifiées, comptes, clés SSH
sudo ls -la /etc/cron.* /etc/crontabs /var/spool/cron/crontabs/ /var/spool/cron 2>/dev/null
sudo crontab -l -u www-data 2>/dev/null   # (apache ou nginx selon la distribution)
awk -F: '$3 == 0 {print "uid 0 :", $1}' /etc/passwd
awk -F: '$3 >= 1000 {print $1, $6, $7}' /etc/passwd
sudo find / -name authorized_keys -newerct '2026-10-15' 2>/dev/null

# Connexions établies hors ports de service locaux (le port 443 distant n'est PAS exclu : les C2 l'utilisent)
sudo ss -tnp state established '( sport != :22 and sport != :80 and sport != :443 )'

Si quelque chose cloche, coupez le serveur du réseau et copiez les journaux. Une fois PHP corrigé (pas avant), changez les secrets : base de données, clés d'API, comptes administrateur. Faites appel à un spécialiste de la réponse à incident si besoin.

Dernière mise à jour des informations : 22 octobre 2026. Sources : avis GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, Help Net Security, JFrog. Commandes fournies sans garantie : testez et sauvegardez avant d'agir.