Corriger PHP2Shell · guide de mise à jour

Corriger PHP2Shell

La correction, c’est une mise à jour de PHP suivie d’un redémarrage. Aucun changement de configuration, mise à jour d’extension ni règle WAF ne la remplace. Les commandes pour chaque plateforme courante, et comment prouver que le correctif est bien en place.

Dernière vérification 2026-10-22

Versions cibles

8.5.12, 8.4.27, 8.3.36, 8.2.35 ou plus récentes — ou un paquet de votre éditeur d’OS dont le changelog mentionne CVE-2026-109618 et CVE-2026-109619. PHP 8.1 et plus ancien ne reçoivent pas de nouvelle version — voir plus bas.

BrancheVulnérableCorrigé dans
8.5< 8.5.128.5.12
8.4< 8.4.278.4.27
8.3< 8.3.368.3.36
8.2< 8.2.358.2.35
8.1 · 8.0 · 7.4toutesRétroportage source seulement
5.4 – 7.3toutesAucun correctif

1. Recenser chaque environnement PHP

Les environnements oubliés sont la première raison pour laquelle un parc reste exposé. Lancez ceci sur chaque hôte.

shell
# PHP processes running right now, and when they started
ps -eo pid,lstart,cmd | grep -E '[p]hp-fpm|[h]ttpd|[a]pache2|[f]rankenphp|[l]sphp'

# CLI and FPM can be different builds — check both
php -v
ls /usr/sbin/php-fpm* 2>/dev/null && for f in /usr/sbin/php-fpm*; do "$f" -v | head -1; done

# Is Apache running PHP in-process (mod_php)? That is the highest-risk setup.
apachectl -M 2>/dev/null | grep -i php

# PHP version inside every running container
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

Vérifiez aussi les images de base de votre registre, les runners CI, les environnements de préproduction et de prévisualisation, les appliances qui embarquent PHP et les vieux serveurs que plus personne ne gère. Depuis l’extérieur, curl -sI https://site | grep -i x-powered-by révèle parfois la version, mais la plupart des sites la masquent. Consultez l’inventaire NCSC-NL pour PHP embarqué ; confirmez le statut auprès de chaque éditeur.

2. Installer la version corrigée

Couvre les paquets de l’OS et le PPA / packages.sury.org d’Ondřej Surý. Les paquets standard de Debian/Ubuntu gardent leur ancien numéro amont et rétroportent le correctif : c’est la vérification du changelog qui fait foi.

shell
sudo apt update

# Upgrade only the PHP packages that are installed
sudo apt install --only-upgrade $(dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' 'php*' | awk '$1=="ii"{print $2}')

# Proof the fix is in: the changelog should mention the CVE
# (replace 8.3 with your version)
apt changelog php8.3-common 2>/dev/null | grep -m1 -E 'CVE-2026-10961[89]' || echo 'NOT FIXED in this package yet'

3. Redémarrer tout ce qui exécute PHP

Installer un paquet remplace des fichiers sur le disque. Les processus en cours continuent d’exécuter l’ancien code vulnérable jusqu’à leur redémarrage.

shell
# Debian / Ubuntu (adjust the version)
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2        # if using mod_php

# RHEL family
sudo systemctl restart php-fpm httpd

# Anything still mapped to the old, deleted PHP binary needs a restart
sudo grep -l -E '(php|libphp)[^ ]* \(deleted\)' /proc/[0-9]*/maps 2>/dev/null
sudo needrestart -r l                 # Debian/Ubuntu helper, if installed

# Long-running PHP workers
php artisan queue:restart             # Laravel queues
php artisan octane:reload             # Octane (Swoole / RoadRunner / FrankenPHP)
sudo supervisorctl restart all        # supervisor-managed workers

4. Vérifier du point de vue du serveur web

shell
# Version of the FPM binary that actually serves traffic
php-fpm8.3 -v 2>/dev/null || php-fpm -v

# Compare process start times with when you upgraded
ps -o pid,lstart,cmd -C php-fpm8.3,php-fpm,apache2,httpd

# Ask the web server itself (use a random name, delete straight after)
F="v-$(openssl rand -hex 8).php"
echo '<?php echo PHP_VERSION;' | sudo tee /var/www/html/$F >/dev/null
curl -s https://your-site.example/$F; echo
sudo rm /var/www/html/$F

Nouveau comportement après le correctif

Le correctif remplace l’interruption sur OOM par une limite souple vérifiée à un point sûr, plus une seconde limite mémoire stricte, plus élevée, qui termine immédiatement le processus avec _exit(). Quand cette limite stricte est atteinte, les fonctions d’arrêt et les destructeurs ne s’exécutent pas. Si votre application travaille dans register_shutdown_function (journalisation, nettoyage), testez les chemins gourmands en mémoire après la mise à jour.

Sur PHP 8.1, 8.0, 7.4 ou plus ancien ?

Ces branches sont en fin de vie. Le projet PHP ne publiera pas de versions pour elles, mais vu la gravité, il a publié des rétroportages source minimaux.

  1. Idéal : migrer vers PHP 8.4 ou 8.5. S’il faut aller vite, 8.3 est un saut plus court depuis 8.1 (8.2 perd son support fin 2026).
  2. Paquet d’OS : Ubuntu (y compris Ubuntu Pro / ESM), Debian LTS, RHEL et d’autres éditeurs LTS ont reçu les correctifs en avance. Cherchez la CVE dans le changelog de votre paquet, comme ci-dessus.
  3. Compilation depuis les sources : les branches de rétroportage de l’équipe PHP — PHP 8.1, PHP 8.0, PHP 7.4. Elles corrigent uniquement ces deux CVE ; la branche reste sans support.
  4. Branches plus anciennes : aucun rétroportage source du projet PHP n’est indiqué en dessous de cette plage. Les distributions peuvent toutefois fournir des correctifs : Ubuntu confirme des paquets corrigés, y compris pour des branches anciennes via Pro / ESM. Vérifiez la couverture des deux CVE et redémarrez les workers ; sans version corrigée, isolez l’hôte et migrez.

5. Ensuite

  • Retirez les atténuations temporaires qui pénalisent les performances, comme pm.max_requests = 1 ou memory_limit = -1, et revenez à des limites raisonnables.
  • Cherchez des traces d’exploitation antérieure : guide de détection. Corriger n’annule pas une compromission.
  • Sur PHP 8.2 ? Son support de sécurité s’arrête le 2026-12-31. Planifiez dès maintenant le passage à 8.4 ou 8.5, tant que la procédure est fraîche.

Voir aussi