Corriger PHP2Shell : mettre à jour PHP et redémarrer les workers

Versions cibles

• PHP 8.5.12 ou plus récent dans la branche 8.5
• PHP 8.4.27 ou plus récent dans la branche 8.4
• PHP 8.3.36 ou plus récent dans la branche 8.3
• PHP 8.2.35 ou plus récent dans la branche 8.2
• Tout ce qui est plus ancien : passer à l’une de ces versions ou confirmer un rétroportage du fournisseur et le traiter comme une transition. La CISA conseille de déconnecter PHP non corrigé si aucune mise à jour n’est possible, y compris explicitement PHP 8.1 et antérieures.

Les archives sources et les builds Windows se trouvent sur la page de téléchargement de PHP. Selon php.net, les distributions Linux et les fournisseurs LTS ont reçu les correctifs avant la publication, si bien que le paquet de la distribution est souvent la bonne voie. Le même avis indique que le dépôt bénévole Remi (rpms.remirepo.net) n’avait pas les mises à jour le 21 octobre et conseille à ses utilisateurs de passer aux paquets de la distribution ou de compiler eux-mêmes.

Debian, Ubuntu et autres systèmes apt

Debian a publié des correctifs : DLA-4848-1 (Debian LTS) pour Debian 12 bookworm, php8.2 8.2.35-1~deb12u1, et DSA-6574-1 pour Debian 13 trixie, php8.4 8.4.27-1~deb13u1. Le security tracker indique comme vulnérables les builds de la suite de base (bookworm php8.2 8.2.32-1~deb12u1, trixie php8.4 8.4.24-1~deb13u1) ; le correctif n’arrive donc que si la suite security figure dans vos sources de paquets. Le 22 octobre, le tracker indiquait toujours testing (forky) php8.4 8.4.26-1 comme vulnérable.

Mettez à jour les métadonnées et installez les paquets PHP réellement publiés. Les noms suivent la branche mineure (php8.3-fpm, php8.3-cli, php8.3-common ainsi que le paquet du module Apache pour mod_php). Si la version candidate est encore inférieure au correctif, attendez la distribution : il ne vous manque pas une option.

sudo apt-get update
apt-cache policy php8.3-cli php8.3-fpm php8.3-common
sudo apt-get install --only-upgrade php8.3-cli php8.3-fpm php8.3-common
php8.3 -v
# Web SAPI, not just the CLI:
php-fpm8.3 -v
sudo systemctl restart php8.3-fpm
# If Apache loads mod_php, restart Apache as well:
sudo systemctl restart apache2

RHEL, Alma, Rocky, Fedora : dnf ou yum

sudo dnf clean expire-cache
sudo dnf update php php-cli php-fpm php-common
php -v
php-fpm -v
sudo systemctl restart php-fpm
# mod_php under httpd:
sudo systemctl restart httpd

Docker et autres images

Reconstruire et redéployer. Récupérer une nouvelle image de base ne change rien tant que la charge de travail qui sert le trafic n’est pas remplacée. Les tags d’images officielles suivent généralement la version de PHP ; vérifiez sur Docker Hub que le tag existe avant de le fixer. La consigne de Google Cloud pour Cloud Run et GKE est la même : reconstruire l’image déployée, sauf pour une image de base serverless que Google dit remplacer lui-même.

FROM php:8.3.36-fpm
# or: php:8.3.36-apache, php:8.4.27-fpm, php:8.2.35-fpm, php:8.5.12-cli

# then, on the host:
# docker pull php:8.3.36-fpm
# docker build -t your-app:php2shell-fix .
# redeploy and confirm the running container's PHP version

cPanel

1. Mettez à jour cPanel lui-même pour qu’EasyApache propose un build PHP corrigé. Les menus évoluent ; la documentation cPanel fait foi.
2. Dans WHM, ouvrez EasyApache 4 et déployez une version de PHP égale ou supérieure au correctif de la branche. Dans MultiPHP Manager, attribuez une version de PHP aux domaines.
3. Retirez les domaines exposés publiquement des gestionnaires PHP 8.1 ou antérieurs, sauf si votre fournisseur a confirmé que le build contient le rétroportage.
4. Redémarrez Apache et PHP-FPM via WHM, vérifiez la version de PHP d’un domaine et supprimez les pages de test temporaires.

Plesk

1. Installez les mises à jour de Plesk et des paquets système. Le chemin de clics actuel est décrit dans la documentation Plesk.
2. Sous Outils et paramètres, vérifiez les mises à jour et la liste des gestionnaires PHP. Les paramètres PHP du domaine indiquent quelle version un abonnement utilise réellement.
3. Choisissez un gestionnaire corrigé (8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou un build fournisseur vérifié). Appliquez-le d’abord aux sites publics.
4. Redémarrez le service PHP utilisé par Plesk et vérifiez la version au niveau du domaine, pas seulement sur l’hôte du panneau.

宝塔面板 (BT Panel)

Selon l’avis 宝塔 du 22 octobre 2026, les panneaux Linux et Windows ont synchronisé 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Les paquets 7.4.34, 8.0.31 et 8.1.35, proposés uniquement pour Linux, sont des builds 宝塔 et non des versions du projet PHP. Le chemin de clics et le réglage Windows incomplet figurent sur la page BT Panel.

mod_php comparé à PHP-FPM

Les deux figurent sur la liste de risques du projet PHP. mod_php est considéré comme le risque le plus élevé parce que le chemin démontré sans authentification agit avant le code applicatif. Un redémarrage d’Apache recharge mod_php. PHP-FPM est un processus distinct : redémarrez chaque pool (systemctl restart php8.3-fpm ou l’unité équivalente) et n’oubliez pas que des pools peuvent fixer leur propre binaire. Le php présent dans le PATH de votre shell peut être un autre build que celui du pool. PHP cite FrankenPHP, php-cgi et LiteSpeed comme servant des requêtes web et donc affectés ; suivez leurs guides de mise à niveau au lieu de supposer qu’un paquet apt php-fpm les couvre.

Mesures provisoires, incomplètes selon PHP

Utilisez-les uniquement comme transition, reprises de l’avis de php.net. Elles réduisent certains chemins et ne rendent pas un hôte sûr. Définissez-les dans php.ini ou dans un réglage de pool ou Apache au niveau administrateur (php_admin_value). Selon PHP, ini_set() et les .user.ini par répertoire interviennent trop tard pour le chemin d’envoi de session.

CVE-2026-109618

• memory_limit=-1, fixé de sorte que l’application ne puisse plus définir de limite finie. Selon PHP, cela supprime l’erreur de limite mémoire contrôlable, mais une erreur d’allocation sous-jacente peut toujours atteindre la faille.
• Un post_max_size bas. PHP recommande 8M sans envoi de fichiers et 32M avec, upload_max_filesize restant inférieur à post_max_size.
• Des limites de taille de requête sur le serveur web ou le proxy, y compris pour les requêtes sans Content-Length exploitable. PHP cite la taille de requête décodée, le nombre de champs d’entrée, les parties multipart, les en-têtes et la profondeur d’imbrication.
• Une limite de conteneur ou de cgroup comme borne de disponibilité qui met fin au worker concerné. PHP déconseille d’utiliser RLIMIT_AS ou RLIMIT_DATA, qui peuvent déclencher l’erreur d’allocation vulnérable.

CVE-2026-109619

• session.upload_progress.enabled=0, puis redémarrer chaque worker. Selon PHP, cela bloque les chemins de session confirmés, pas les autres variantes.
• Uniquement pour PHP 8.5 : fatal_error_backtraces=0, puis redémarrer. Selon PHP, cela ne bloque que le chemin confirmé via les backtraces d’erreurs fatales.
• Supprimer les réglages par requête invalides ou obsolètes qui émettent des diagnostics avant l’initialisation. Désactiver les erreurs avec error_reporting, display_errors ou @ ne ferme pas la faille.
• Corriger les erreurs fatales et dépassements de délai qu’un attaquant peut atteindre, y compris dans les callbacks et le nettoyage après des envois ou des imports. C’est la formulation du projet ; il s’agit d’un conseil de durcissement, pas d’une affirmation qu’un code applicatif sans erreur rend FPM sûr.

Pare-feu applicatifs web (WAF)

La CISA indique qu’un pare-feu applicatif web peut offrir une certaine protection jusqu’à la mise à jour. Cloudflare indique que des règles gérées pour ce problème étaient actives dès le 21 octobre 2026 à 03 h 02 UTC pour les clients des offres WAF gratuites et payantes, développées sous embargo avec la PHP Foundation et d’autres, et que les clients devaient tout de même corriger. Une règle peut être contournée ; Cloudflare a lui-même observé des attaquants adapter leurs charges. Gardez le WAF, mais ne l’utilisez pas comme correctif.

Le bulletin AWS 2026-143-AWS liste des contrôles compensatoires pour les utilisateurs d’AWS WAF. Pour CVE-2026-109618 : la règle SizeRestrictions_BODY du Core rule set (CRS) d’AWS WAF, comme protection supplémentaire contre les corps de requête de plus de 8 Ko (8 192 octets). Pour CVE-2026-109619 : AWS a publié la version 2.3 du groupe de règles gérées AWS WAF PHP et l’a promue version par défaut dans le monde entier. Le bulletin publie aussi, en JSON, une règle personnalisée qui bloque les requêtes POST contenant PHP_SESSION_UPLOAD_PROGRESS dans le corps et PHPSESSID dans le corps ou un cookie. AWS rappelle lui aussi que seule la mise à niveau corrige complètement, et que les versions EOL 5.4 à 8.1 n’ont aucun correctif pour CVE-2026-109618.

Après la mise à niveau

• Vérifiez la version au niveau de la SAPI qui répond aux requêtes HTTP et redémarrez-la. Expel et l’Université de Toronto insistent tous deux sur le redémarrage.
• Priorisez les systèmes exposés publiquement, puis tout ce qui traite des envois ou imports non fiables, puis les appliances. Le NCSC britannique et le Centre canadien pour la cybersécurité indiquent tous deux que les produits tiers embarquant PHP nécessitent leurs propres mises à jour éditeur.
• Si un hôte a été exposé et n’a pas pu être corrigé rapidement, la CISA conseille de rechercher des workers PHP qui lancent des shells ou téléchargent des outils. Le NCSC britannique conseille de rechercher des portes dérobées avant de faire confiance à un hôte exposé puis mis à jour. Nous ne pouvons y ajouter aucune liste d’indicateurs vérifiée. Elastic Security Labs (21 octobre) détaille la même approche comportementale : surveiller les serveurs web ou workers PHP qui lancent des shells, téléchargent des outils avec curl ou wget, ou écrivent de nouveaux fichiers de script dans la racine web.
• Les notes du NCSC-NL liées dans l’avis britannique sont un inventaire de départ de produits, pas une attestation qu’un produit non listé est sans risque.

Durcissement à garder après la mise à jour

L’avis complet de PHP recommande des limites en bordure (taille décodée, profondeur d’imbrication, variables d’entrée, parties multipart et en-têtes par partie), le refus du multipart sur les routes sans upload, et d’éviter RLIMIT_AS et RLIMIT_DATA. Pourquoi les limites d’upload seules ne plafonnent pas la mémoire, et les différences entre mod_php, FPM, FrankenPHP et LiteSpeed : voir la page CVE-2026-109618.