PHP2Shell : mettez à jour PHP sur vos sites web et vos pare-feu

Ce qui se passe

Mardi 20 octobre, l’équipe de développement de PHP a annoncé la publication imminente de correctifs pour deux failles qu’elle classe comme critiques. Les nouvelles versions sont sorties le lendemain, mercredi 21 octobre : PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Le CERT-FR, le centre gouvernemental de veille et d’alerte rattaché à l’ANSSI, a publié une alerte le jour même.

Les attaques n’ont pas attendu. Amazon dit avoir repéré une première tentative dès le 17 octobre, quatre jours avant l’annonce, puis plusieurs outils d’attaque différents le 21. Cloudflare comptait des millions de tentatives dès le 22 octobre, dont certaines cherchent à enrôler les serveurs dans le réseau de machines piratées Mirai. Aucune intrusion réussie n’était encore confirmée au 23 octobre, mais tout serveur non corrigé doit être considéré comme visé.

PHP fait tourner une très grande partie des sites web : WordPress, PrestaShop, Joomla, Drupal, et une foule d’applications internes (extranet, gestion de parc, outils métier). Selon l’équipe de PHP, toutes les installations qui servent des pages web sont concernées, quel que soit le mode de fonctionnement du serveur (PHP-FPM, Apache avec mod_php, CGI, FrankenPHP, LiteSpeed).

La faille en clair

Quels risques pour votre entreprise ?

Êtes-vous concerné ?

Vous l’êtes si vous avez un site web, une boutique en ligne ou une application web en PHP, chez un hébergeur ou sur vos propres serveurs, et que sa version de PHP est antérieure aux versions corrigées. Pour un site en hébergement mutualisé, c’est l’hébergeur qui met PHP à jour : vérifiez qu’il l’a fait, ou choisissez une version corrigée dans votre espace client.

Les versions 8.1 et plus anciennes ne reçoivent plus de mise à jour officielle. L’équipe de PHP fournit seulement des correctifs à intégrer soi-même pour les versions 7.4, 8.0 et 8.1 : le vrai remède est de passer à une version maintenue. Profitez-en pour viser au moins PHP 8.3, car la branche 8.2 arrive en fin de vie le 31 décembre 2026.

Que faire maintenant

1. Faites la liste de ce qui tourne en PHP. Site vitrine, boutique, extranet, outils internes, et l’interface d’administration de votre pare-feu s’il s’agit d’un pfSense ou d’un OPNsense.
2. Relevez la version de PHP de chacun. Dans l’espace client de votre hébergeur, dans WordPress (Outils, puis Santé du site, onglet Informations, rubrique Serveur) ou, sur vos serveurs, avec la commande php -v.
3. Mettez PHP à jour, puis redémarrez le service. Sur un serveur, installez la mise à jour puis redémarrez PHP-FPM ou Apache : tant qu’ils ne sont pas relancés, l’ancienne version reste en mémoire. En mutualisé, demandez confirmation à votre hébergeur s’il ne l’a pas annoncé.
4. Si la mise à jour doit attendre quelques heures, réduisez le risque. C’est l’affaire de votre hébergeur ou de votre administrateur, et chaque faille a sa parade temporaire selon PHP et le CERT-FR. Contre CVE-2026-109619 : désactiver le suivi de progression des envois de fichiers dans le php.ini ou le pool PHP-FPM (php_admin_flag[session.upload_progress.enabled] = off, pas dans un fichier .user.ini), puis redémarrer. Contre CVE-2026-109618 : imposer memory_limit=-1 par php_admin_value (pour que les applications ne puissent pas le changer), réduire post_max_size (8M, ou 32M si le site reçoit des fichiers) et limiter la taille des requêtes au niveau du serveur web. Sur PHP 8.5, ajouter fatal_error_backtraces=0. Aucune de ces parades ne remplace la mise à jour.
5. Mettez à jour vos pare-feu pfSense et OPNsense. Netgate a publié le 21 octobre une mise à jour de PHP pour pfSense, à appliquer en ligne de commande (SSH ou console) et non depuis l’interface web. Elle passe en priorité si vous utilisez le portail captif, qu’il soit ouvert sur Internet ou non. Côté OPNsense, les versions 26.7.7 et Business 26.4.2p3 embarquent un PHP corrigé ; redémarrez ensuite le service de portail captif si vous l’utilisez.

Comment vérifier

Une fois la mise à jour faite, contrôlez la version réellement utilisée par le site, pas seulement celle installée sur le serveur. Dans WordPress, l’écran Santé du site affiche la version en service. En ligne de commande, php -v donne la version de l’outil en ligne de commande, qui peut différer de celle de PHP-FPM : vérifiez aussi le paquet et le service PHP-FPM.

Tant qu’un serveur n’est pas corrigé, le CERT-FR recommande d’abord de l’isoler. À défaut, il propose une parade temporaire qu’il n’a pas validée : bloquer au niveau du pare-feu applicatif web les requêtes d’envoi de fichiers (dites « multipart »), ou au moins les surveiller. Passez aussi en revue les journaux du serveur depuis le 17 octobre : des envois inhabituels suivis de fichiers ou de processus inconnus méritent une analyse. Si vous manquez de temps pour faire ce tour, c’est exactement le type de vérification que nous menons lors d’un audit cybersécurité.