PHP2Shell : ce qu'est la faille PHP et comment la corriger

La faille PHP baptisée PHP2Shell regroupe deux bugs critiques situés dans PHP lui-même, suivis sous les identifiants CVE-2026-109618 et CVE-2026-109619. Ils peuvent permettre à un attaquant non authentifié d'exécuter du code sur n'importe quel serveur qui sert des pages PHP. Le correctif passe par une mise à jour de PHP : 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou le paquet corrigé de votre distribution, suivie d'un redémarrage de chaque worker PHP.

Les détails ont fuité le 20 octobre, deux jours avant la divulgation prévue, et le projet PHP a avancé la sortie des correctifs d'un jour, au 21 octobre. Si vous faites tourner quoi que ce soit en PHP (WordPress, WooCommerce, PrestaShop, Drupal, Magento, Laravel, un panneau d'administration), vérifiez votre version aujourd'hui.

Qu'est-ce que la faille PHP PHP2Shell ?

PHP2Shell est le nom que les chercheurs ont donné à deux bugs d'exécution de code à distance (RCE) dans le moteur PHP. Ils ont été signalés par des chercheurs de Calif, Wiz, OpenAI et du français Quarkslab. PHP attribue aux deux une note de 9,2 en CVSS v4.0.

C'est une faille de sécurité PHP au sens strict : les bugs se trouvent dans la façon dont PHP analyse une requête entrante, avant même que le code de votre application ne démarre. Mettre à jour WordPress, une extension ou votre framework ne change rien ici. C'est le binaire PHP qui doit changer.

L'avis de sécurité de PHP cite toutes les configurations qui servent des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Il place Apache avec mod_php au niveau de risque le plus élevé, avec un exploit démontré où une seule requête non authentifiée déclenche l'attaque avant l'exécution de tout code applicatif. L'avis décrit aussi une RCE passant par la fonction de suivi de progression des uploads de session (session upload progress) sous PHP-FPM, quand l'application réunit certaines conditions.

Quelles versions de PHP sont touchées ?

Toutes celles qui précèdent les quatre versions corrigées. Voici ce que disent l'avis de PHP et ses versions de sécurité du 21 octobre :

Cloudflare et Imperva affirment que les bugs remontent jusqu'à PHP 5.4. L'avis de PHP considère comme touchées toutes les versions inférieures aux versions corrigées, sans nommer de première version affectée.

Un numéro de version qui paraît ancien peut tout à fait être corrigé. Les distributions Linux rétroportent les correctifs et conservent l'ancien numéro amont. Ubuntu 24.04 livre le correctif sous 8.3.6-0ubuntu0.24.04.13, qui affiche toujours 8.3.6. Debian 12 propose 8.2.35-1~deb12u1 (DLA-4848-1) et Debian 13 8.4.27-1~deb13u1 (DSA-6574-1). Comparez la version complète du paquet avec le suivi de sécurité de votre distribution, pas seulement les trois premiers chiffres.

La faille PHP2Shell est-elle exploitée ?

Les informations se contredisent, et elles changent d'heure en heure. Voici ce que les sources ont dit, dans l'ordre :

• 17 octobre : Amazon Threat Intelligence a enregistré une tentative d'exploitation de PHP2Shell sur ses honeypots MadPot, quatre jours avant les correctifs. La requête venait d'une adresse IP liée à un service commercial d'anonymisation.
• 20 octobre : les détails fuitent en ligne. watchTowr confirme que les bugs sont réels. Huntress dit n'avoir observé aucune exploitation et ne connaître aucun code d'exploit public.
• 21 octobre, 03:02 UTC : Cloudflare active des règles WAF pour PHP2Shell. L'entreprise a ensuite écrit avoir vu du trafic d'attaque contre ses clients, les attaquants modifiant la charge utile pour contourner les règles.
• 21 octobre, 14:00 UTC : PHP publie les correctifs. Le même jour, watchTowr signale l'exploitation des deux bugs sur son réseau de honeypots.
• 21 octobre, après-midi (heure des États-Unis) : le directeur exécutif de la PHP Foundation déclare à CNBC n'avoir aucune preuve d'exploits fonctionnels, seulement des exploits générés « incomplets, mal orientés et non fonctionnels ». Imperva n'a relevé aucun trafic correspondant pendant sa propre surveillance avant la divulgation.
• 23 octobre : aucune des deux CVE ne figure encore dans le catalogue Known Exploited Vulnerabilities de la CISA (dernière mise à jour le 21 octobre).

Les chercheurs ont construit des exploits fonctionnels, et d'autres équipes disent avoir reproduit les bugs. Partez du principe que les attaquants en sont capables aussi. Tout serveur PHP non corrigé et exposé à Internet doit être considéré comme vulnérable.

Comment vérifier votre version de PHP

Vérifiez le PHP qui sert les requêtes web. Sur beaucoup de serveurs, le PHP en ligne de commande n'est pas la même build que celui qui fait tourner le site.

Sur le serveur :

php -v                     # command line PHP
php-fpm8.3 -v              # the FPM build (the name varies: php-fpm, php-fpm8.4)
apachectl -M | grep php    # a php_module line means Apache runs PHP as mod_php
dpkg -l | grep php         # Debian/Ubuntu: the full package versions
rpm -qa | grep php         # RHEL, Rocky, Alma, Fedora

Depuis le navigateur : déposez à la racine web un fichier info.php contenant <?php phpinfo();, ouvrez-le, puis lisez la version en haut de page et la ligne Server API (elle indique FPM, Apache 2.0 Handler ou CGI). Supprimez le fichier juste après : il expose toute votre configuration.

Dans WordPress : allez dans Outils > Santé du site > Infos et ouvrez Serveur. La ligne de version PHP est celle qui fait tourner votre site.

Dans un panneau d'hébergement : cPanel l'affiche dans MultiPHP Manager ou Select PHP Version, Plesk dans les paramètres PHP du domaine, et la plupart des hébergeurs infogérés sur la page de présentation du site.

Avec Docker : docker exec <container> php -v renvoie le PHP du conteneur en cours d'exécution, et c'est celui-là qui compte.

Pour tester depuis l'extérieur, Searchlight Cyber a publié un outil open source, php2shell-scanner, selon Help Net Security. Ne le lancez que contre des hôtes qui vous appartiennent.

Comment corriger la faille PHP2Shell

Un ordre vaut pour toutes les architectures : les serveurs exposés à Internet d'abord, puis le redémarrage de chaque processus PHP. Un binaire corrigé sur le disque ne sert à rien tant que les anciens workers continuent de servir des requêtes.

Debian et Ubuntu

sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm   # match your version
sudo systemctl restart apache2      # if you use mod_php

Contrôlez ensuite les versions des paquets avec dpkg -l | grep php dans le suivi de sécurité Debian ou Ubuntu. Sur Ubuntu 20.04 et antérieures, les paquets 7.x corrigés passent par Ubuntu Pro. Les dépôts tiers se mettent à jour à leur propre rythme : Help Net Security a rapporté que rpms.remirepo.net n'avait pas de mise à jour le jour de la sortie, donc vérifiez que le vôtre a bien publié la sienne avant de compter dessus. Même réflexe pour le dépôt deb.sury.org (PPA ondrej/php), souvent utilisé pour installer plusieurs versions de PHP sur Debian et Ubuntu : regardez quelle version il propose.

RHEL, Rocky, AlmaLinux et Fedora

Lancez sudo dnf upgrade 'php*', puis redémarrez php-fpm et httpd. Consultez l'avis de votre éditeur pour connaître la version de paquet corrigée, car elle ne correspondra pas au numéro amont.

Images Docker

Les images officielles php sur Docker Hub ont reçu les tags 8.5.12, 8.4.27, 8.3.36 et 8.2.35 le 21 octobre. Fixez-en un, reconstruisez et redéployez :

FROM php:8.4.27-fpm

docker compose build --pull && docker compose up -d

Un conteneur en cours d'exécution garde son ancien PHP jusqu'à ce que vous le remplaciez. Les images construites sur php (y compris wordpress) demandent elles aussi un nouveau pull et un redéploiement.

Hébergement mutualisé et cPanel

Ici, vous ne pouvez pas corriger PHP vous-même. L'hébergeur met à jour les builds PHP proposées par le panneau (ea-php d'EasyApache ou alt-php de CloudLinux sur la plupart des serveurs cPanel). Chez OVHcloud, la version de PHP se choisit dans l'espace client ou dans le fichier .ovhconfig. o2switch et bien d'autres passent par cPanel et son outil Select PHP Version, et Plesk reste courant. Dans tous les cas, c'est l'hébergeur qui corrige PHP. Consultez sa page d'état ou demandez au support si ses builds PHP intègrent les correctifs de CVE-2026-109618 et CVE-2026-109619. Si votre site tourne encore en 7.4 ou 8.1, passez-le en 8.3 ou plus récent dans MultiPHP Manager, Select PHP Version ou l'équivalent chez votre hébergeur, après un test sur une copie de préproduction si vous en avez une.

Hébergement WordPress infogéré

Votre hébergeur corrige PHP à votre place. WordPress.org indique qu'aucune mise à jour de WordPress n'est nécessaire ni prévue pour ces bugs. Vérifiez que l'hébergeur a bien déployé le correctif, puis contrôlez Santé du site > Infos > Serveur. Si le site tourne en PHP 8.1 ou antérieur, faites-le monter de version : ces branches ne reçoivent plus que des rétroportages d'éditeurs.

Windows et compilation depuis les sources

Les sources corrigées et les binaires Windows sont disponibles sur la page de téléchargement de php.net. Pour 7.4, 8.0 et 8.1, PHP a publié des rétroportages minimaux du code source à l'intention de ceux qui compilent PHP eux-mêmes.

Si vous ne pouvez pas corriger aujourd'hui

PHP est sans ambiguïté sur ce point : seule une mise à jour corrige complètement le problème. Son avis liste des réglages qui bloquent certains chemins d'attaque sans pour autant rendre un serveur sûr :

• Définissez session.upload_progress.enabled=0 dans php.ini, dans le pool FPM ou dans la configuration du serveur (pas via ini_set() ni .user.ini), puis redémarrez chaque worker. Cela ferme les chemins confirmés qui passent par les sessions.
• Sous PHP 8.5, définissez fatal_error_backtraces=0 et redémarrez chaque worker.
• Définissez memory_limit=-1 d'une manière que les applications ne peuvent pas surcharger, par exemple avec php_admin_value. Associez-le à un post_max_size bas (8M sans upload, 32M avec) et à une limite mémoire au niveau du conteneur ou du cgroup. N'utilisez pas RLIMIT_AS ni RLIMIT_DATA, qui peuvent déclencher le bug.
• Plafonnez au niveau du serveur web ou du proxy la taille des requêtes, le nombre de champs, le nombre de parties multipart et la profondeur d'imbrication, et refusez les requêtes multipart si le site n'accepte jamais d'upload.

Testez chaque changement avant de le déployer, car certains cassent les uploads. Si un serveur ne peut être ni corrigé ni protégé à temps, le NCSC britannique et WordPress.org conseillent tous deux d'envisager de le mettre hors ligne, ou de le placer derrière un VPN ou une liste d'autorisation pour que seules des adresses connues puissent l'atteindre.

Réduire l'exposition pendant la correction

Rien de ce qui précède n'empêche un scanner d'envoyer des requêtes. L'exploitation de masse d'une faille critique toute fraîche est automatisée : des scripts balaient Internet à la recherche de serveurs PHP et envoient l'exploit à chacun. Ces scanners tournent le plus souvent sur des serveurs loués dans des réseaux d'hébergement et de datacenters, ou passent par des VPN, des proxys et Tor. La première détection d'Amazon venait justement d'un service d'anonymisation. Les vrais visiteurs, eux, naviguent rarement depuis un datacenter.

Cela vous donne une seconde couche de protection pour les jours qu'il faut pour tout corriger : refuser les requêtes issues de ces réseaux avant qu'elles n'atteignent PHP. IPScanner ne détecte pas PHP2Shell et ne corrige pas PHP. Il vérifie qui se connecte, range chaque visiteur dans une classe (humain, crawler vérifié, automatisation malveillante, hébergement, Tor, VPN, proxy et quelques autres) et bloque les classes que vous choisissez.

La vérification doit avoir lieu devant PHP. PHP2Shell se déclenche pendant que PHP analyse la requête, donc tout ce qui s'exécute dans PHP arrive trop tard.

L'extension WordPress et les contrôles WooCommerce arrêtent les fausses inscriptions, le spam et le card testing au niveau de vos formulaires. Pour PHP2Shell, ce n'est pas la bonne couche. Pour un site WordPress hébergé sur un seul serveur Apache, sans rien devant, la passerelle la plus rapide à mettre en place consiste à placer Cloudflare et le Worker devant lui.

Commencez en mode monitor, bloquez ensuite. Le mode monitor enregistre chaque verdict sans rien bloquer : vous voyez qui sollicite vos endpoints PHP avant de toucher à quoi que ce soit. Au bout de quelques heures, passez l'hébergement, Tor et l'automatisation malveillante en blocage. Pour les VPN et les proxys, c'est une question de jugement : bloquez-les sur un panneau d'administration, réfléchissez à deux fois sur une boutique ouverte au public. Les moteurs de recherche et crawlers IA vérifiés de l'annuaire des crawlers passent toujours.

Le blocage nécessite le plan Starter. Avec le plan Free, un site tourne uniquement en mode monitor. Les nouveaux comptes disposent de sept jours de fonctions Starter sans carte bancaire, de quoi couvrir une fenêtre de correction. Voir les tarifs.

Soyez lucide sur les limites :

• Un attaquant sur une connexion domestique ou derrière un proxy résidentiel que les contrôles ne repèrent pas atteint toujours PHP.
• Les passerelles laissent passer en cas de problème (fail open). Si l'API IPScanner est lente ou injoignable, les requêtes passent, et le site reste en ligne.
• Une passerelle n'aide que si le trafic la traverse. Si votre origine répond sur son IP publique, un scanner contourne tout simplement Cloudflare : n'acceptez sur l'origine que les connexions venant des plages d'IP de Cloudflare.

Si votre site est derrière Cloudflare, laissez aussi actives ses règles WAF managées. Cloudflare indique que ses règles PHP2Shell tournent par défaut sur toutes ses offres depuis le 21 octobre. Ces règles examinent la requête elle-même, alors qu'IPScanner regarde qui l'envoie. Aucune des deux ne remplace le correctif.

Vérifier si quelqu'un est entré

Si un serveur est resté exposé et non corrigé depuis la mi-octobre, regardez de près avant de passer à autre chose. Les avis de sécurité et les équipes de réponse à incident pointent les mêmes signes :

• des requêtes POST multipart volumineuses ou très imbriquées vers des chemins .php, souvent avec PHP_SESSION_UPLOAD_PROGRESS dans le corps
• des erreurs « Allowed memory size exhausted » et des rafales de workers PHP plantés ou relancés dans les journaux d'erreurs
• des fichiers nouveaux ou modifiés à la racine web, de nouvelles tâches cron ou de nouveaux comptes utilisateurs
• des processus PHP ou du serveur web qui lancent des shells ou ouvrent des connexions sortantes que vous ne reconnaissez pas

Si vous soupçonnez une compromission, isolez le serveur et conservez les journaux avant de redémarrer quoi que ce soit, puis changez tous les secrets que PHP pouvait lire : mots de passe de base de données, clés d'API, clés de session.

Check-list PHP2Shell

1. Recensez toutes vos installations PHP, en commençant par celles exposées à Internet, sans oublier les panneaux d'administration, les appliances et les conteneurs.
2. Trouvez la version qui sert les requêtes web (phpinfo, Santé du site, php-fpm -v), pas seulement php -v.
3. Installez 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou le paquet corrigé de votre distribution.
4. Redémarrez chaque pool PHP-FPM et chaque worker Apache et LiteSpeed ; reconstruisez et redéployez les conteneurs.
5. En 8.1 ou antérieur, obtenez un rétroportage d'éditeur ou mettez à niveau ; si c'est impossible, mettez le site hors ligne ou placez-le derrière une liste d'autorisation.
6. Impossible de corriger tout de suite ? Appliquez les réglages provisoires de PHP et restreignez l'accès.
7. Placez une passerelle devant PHP (Cloudflare, Traefik, Caddy, nginx), en mode monitor d'abord, puis bloquez l'hébergement, Tor et l'automatisation malveillante.
8. Verrouillez votre origine pour qu'elle n'accepte que le proxy placé devant elle.
9. Fouillez vos journaux à partir du 17 octobre à la recherche des signes ci-dessus.
10. Changez les secrets de tout serveur resté exposé sans correctif.

Sources : avis de sécurité PHP, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, WordPress.org, Cloudflare, FAQ watchTowr, watchTowr, Help Net Security, SecurityWeek, The Hacker News, CNBC, Imperva, Qualys, Armis, Ubuntu, Debian.