Corriger PHP2Shell

1 Trouver chaque PHP sur le serveur

De nombreux serveurs exécutent plusieurs PHP : le paquet système, les versions installées par un panneau de contrôle (cPanel EA-PHP, Plesk, CWP/CloudLinux alt-php, DirectAdmin), des conteneurs et des builds en ligne de commande utilisés par cron. Chacun de ceux qui traitent des requêtes web doit être mis à jour.

Exécutez php -v, listez les processus php-fpm avec ps aux | grep php-fpm et consultez le sélecteur PHP de votre panneau.

2 Mettre à jour vers une version corrigée

Les versions amont corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les paquets de distribution peuvent intégrer le correctif sous un numéro de version plus ancien — recherchez CVE-2026-109618 et CVE-2026-109619 dans le changelog.

PHP 8.1 et les versions antérieures ne reçoivent aucune version du projet PHP. Des rétroportages minimaux du code source ont été publiés pour 7.4, 8.0 et 8.1 à l’intention de ceux qui compilent depuis les sources, mais la solution durable consiste à passer à une branche prise en charge.

sudo apt update && sudo apt install --only-upgrade 'php*'
sudo systemctl restart 'php*-fpm' apache2 2>/dev/null
apt changelog php8.3-fpm | grep -i -m3 CVE-2026-1096

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm httpd
rpm -q --changelog php-common | grep -i -m3 CVE-2026-1096

docker pull php:8.3-fpm   # must report 8.3.36 or later
docker compose up -d --build --force-recreate
docker compose exec app php -v

3 Redémarrer tous les processus PHP

Installer un paquet ne modifie pas le code déjà en cours d’exécution. Redémarrez PHP-FPM, Apache (pour mod_php), LiteSpeed, FrankenPHP, les workers de file d’attente et les superviseurs. Pour les conteneurs, reconstruisez ou récupérez la nouvelle image — redémarrer la même image n’installe aucun correctif.

4 Vérifier

Exécutez php -v pour chaque binaire et confirmez que les processus en cours utilisent le nouveau build (par exemple, ls -l /proc/$(pgrep -o php-fpm)/exe ne doit pas indiquer « deleted »). Relancez ensuite cette vérification.

5 Si vous ne pouvez pas mettre à jour aujourd’hui

Appliquez les mesures d’atténuation partielles ci-dessous et limitez l’accès au site jusqu’à ce que vous puissiez mettre à jour. Elles réduisent le risque ; elles ne le suppriment pas.

6 Rechercher des signes de compromission — et renouveler les secrets

Si un site vulnérable était accessible depuis Internet, examinez l’activité à partir du 20 octobre 2026 : plantages de workers PHP (SIGSEGV) dans le journal d’erreurs de PHP-FPM ou d’Apache, fichiers PHP nouveaux ou modifiés dans la racine web, nouvelles tâches cron, nouveaux comptes administrateur et connexions sortantes inattendues.

Comme CVE-2026-109619 peut exposer la mémoire du processus PHP sans qu’aucun code ne soit exécuté, un système de fichiers sain ne prouve pas que rien n’a fuité. Changez les mots de passe des bases de données, les clés d’API, les identifiants de paiement et de messagerie, et invalidez les sessions utilisateur des sites exposés.

7 Après la mise à jour

Le correctif introduit une nouvelle limite de mémoire stricte : un processus qui l’atteint est arrêté immédiatement et les gestionnaires d’arrêt (shutdown handlers) ne s’exécutent pas. Vérifiez le comportement de votre application en cas de forte pression mémoire, revoyez memory_limit avec post_max_size et max_input_nesting_level, et annulez tout memory_limit = -1 temporaire défini avant l’application du correctif. Masquer la version avec expose_php = Off est un durcissement facultatif, pas un correctif.

Mesures d’atténuation partielles (selon php.net et les avis de sécurité)

Elles ne font que restreindre les vecteurs d’attaque connus. php.net indique que la mise à jour est le seul choix sûr.

; php.ini / FPM pool (php_admin_value) — redémarrez ensuite tous les workers
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; PHP 8.5
post_max_size = 8M                ; 32M si les téléversements sont nécessaires
max_input_nesting_level = 16      ; default 64
display_errors = 0

; FPM pool
pm.max_requests = 200

Définissez ces paramètres dans php.ini, dans le pool PHP-FPM (php_admin_value) ou dans la configuration du serveur — pas avec ini_set() ni .user.ini — puis redémarrez les workers. Autres mesures issues des avis et de l’équipe de recherche :

• memory_limit = -1 bloque certains vecteurs qui reposent sur la limite de mémoire propre à PHP, mais confie l’épuisement de la mémoire au système d’exploitation — ne l’utilisez qu’avec une limite cgroup v2 memory.max. N’utilisez pas RLIMIT_AS ni RLIMIT_DATA ; ils peuvent déclencher les mêmes chemins vulnérables.
• Abaissez max_input_nesting_level autant que vos formulaires le permettent.
• Abaissez pm.max_requests de PHP-FPM afin que les workers soient recyclés plus souvent (coût en performances).
• Limites de taille de requête, de nombre de champs et d’imbrication au niveau du serveur web ou du proxy ; supprimez les paramètres INI par requête invalides ou obsolètes.
• Des politiques SELinux ou AppArmor peuvent limiter ce qu’un worker compromis peut exécuter — elles réduisent l’impact, elles n’empêchent pas la divulgation de mémoire.

Références

• php.net — avis de sécurité et annonces de versions
• php.net — PHP 8 ChangeLog
• php.net — versions prises en charge
• php.net — téléchargements
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• The PHP Foundation — Today’s PHP security release
• php2shell.com — Wiz Research × OpenAI Codex Security × Calif
• Wiz Research · OpenAI · Calif

Source : avis de sécurité php.net, 21 octobre 2026. Dernière vérification le 2026-10-23.