php2shell : deux failles critiques PHP, que faire
Sommaire
- Ce qui te concerne
- php2shell : c'est quoi, en clair ?
- Qui est concerné ?
- Comment connaître ta version de PHP
- Que faire aujourd'hui
- La mesure temporaire : désactiver session.upload_progress
- Le prompt à coller dans ton agent
- Pourquoi cacher ta version ne corrige rien
- Vérifier ton site avec Rustine
- Questions fréquentes
- Je ne sais pas quelle version de PHP tourne sur mon serveur, je fais quoi ?
- Mon hébergeur mutualisé va-t-il corriger automatiquement ?
- Je suis sous PHP 7 ou PHP 5, je suis touché ?
- C'est quoi, une exécution de code à distance ?
- Le correctif est déjà disponible ?
- Sources
Le 21 octobre 2026 à 14 h UTC (16 h à Paris), PHP publie un correctif de sécurité hors cycle pour deux failles critiques PHP : CVE-2026-109618 et CVE-2026-109619, surnommées « php2shell ». Chacune est notée 9,2 sur 10 (CVSS v4) et permet une exécution de code à distance (RCE) : un attaquant peut exécuter ses propres commandes sur ton serveur sans connaître ton mot de passe. Si ton site tourne sous PHP — WordPress, Laravel, Symfony ou une app maison — vérifie ta version aujourd'hui et mets à jour dès que la version du 21 octobre est disponible.
Ce qui te concerne
- Versions concernées : les branches encore maintenues 8.2, 8.3, 8.4 et 8.5. PHP 8.1 et plus ancien ne sont plus maintenus et ne recevront pas de correctif officiel.
- Version corrigée : la version publiée le 21 octobre 2026 sur php.net. Je ne cite pas de numéro de version tant que php.net ne l'a pas confirmé dans son changelog.
- Gravité : critique, CVSS v4 9,2, exécution de code à distance dans le cœur de PHP.
- Exploitation : watchTowr a reproduit CVE-2026-109618 en laboratoire. Huntress n'avait observé aucune exploitation au moment de la publication. La situation peut évoluer vite, c'est pour ça qu'on corrige aujourd'hui et pas la semaine prochaine.
php2shell : c'est quoi, en clair ?
Une exécution de code à distance (RCE), c'est la capacité pour un attaquant d'exécuter des commandes sur ton serveur à travers une simple requête HTTP, sans se connecter à ton compte administrateur. Concrètement, s'il y parvient, il peut lire tes fichiers, copier ta base de données, modifier tes pages, installer un accès persistant ou se servir de ton serveur pour autre chose.
Le point important ici : la faille est dans le cœur de PHP, pas dans un plugin ou un framework. Ce n'est pas « une extension WordPress à mettre à jour » : c'est le moteur qui exécute ton code. Une app Laravel, un site WordPress, un script PHP fait main, tous s'appuient sur le même moteur.
Pourquoi ce nom, php2shell ? Parce que l'objectif d'un attaquant est de transformer ton serveur PHP en un shell, c'est-à-dire une porte qui lui permet de taper des commandes. Le surnom circule surtout dans les messages de chercheurs, pas dans l'annonce officielle de PHP.
Détail important sur le calendrier : des détails techniques ont fui avant la date prévue, à la fin d'un embargo. L'équipe sécurité de PHP a donc avancé la publication hors cycle au 21 octobre 2026 à 14 h UTC. Le correctif arrive plus tôt que prévu.
Qui est concerné ?
Tu es concerné si ton site tourne sous PHP, quel que soit le framework :
- WordPress et son écosystème de plugins,
- Laravel ou Symfony,
- une app PHP maison, même un simple formulaire,
- un outil hébergé sur un VPS ou dans un conteneur Docker.
Les vibecodeurs qui génèrent une app avec Lovable, Bolt ou Cursor sortent souvent une stack JavaScript (Next.js, Supabase). Mais beaucoup de freelances et de petites agences livrent encore des sites WordPress ou Laravel, et beaucoup de serveurs font tourner un vieux PHP à côté de l'app principale. Si tu ne sais pas quelle version tourne, considère que tu es concerné tant que tu n'as pas vérifié.
Ce n'est pas la première fois qu'une faille critique touche une stack qu'on déploie sans y penser : la CVE-2025-29927 avait touché le middleware Next.js en 2025. Le réflexe est le même : identifier la version, patcher, vérifier.
Comment connaître ta version de PHP
Quatre façons, de la plus simple à la plus complète.
1. La ligne de commande. Sur ton serveur, en SSH :
php -v
Ça te donne la version utilisée en ligne de commande. Attention : sur certains serveurs, la version CLI et la version web (PHP-FPM ou Apache) peuvent différer. C'est la version web qui compte pour ton site.
2. La page phpinfo(). Crée un fichier temporaire (par exemple verif.php) contenant uniquement <?php phpinfo(); ?>, ouvre-le dans ton navigateur, note la version, puis supprime le fichier. Ne laisse jamais une page phpinfo() en ligne : elle affiche plein d'informations utiles à un attaquant.
3. Le panneau de l'hébergeur. cPanel, Plesk ou les panneaux d'OVH, o2switch, Hostinger affichent presque toujours la version de PHP active pour chaque site, souvent avec un sélecteur pour la changer.
4. Le tag de l'image Docker. Si tu déploies avec Docker, le tag de ton image indique la version : php:8.3-fpm, php:8.2-apache, etc. Un tag php:latest ou php:8 sans numéro complet est un risque : tu ne sais pas exactement ce qui tourne. Regarde docker ps ou ton fichier compose.
Bonus : l'en-tête HTTP X-Powered-By annonce parfois la version de PHP. S'il est masqué (on le fait à la fin), ce n'est pas grave : les quatre méthodes ci-dessus restent valables.
Que faire aujourd'hui
La marche à suivre dépend de qui gère ton serveur.
Si ton site est chez un hébergeur managé (mutualisé, WordPress managé) : vérifie la version affichée dans le panneau, puis surveille la communication de l'hébergeur. La plupart appliqueront le correctif automatiquement ou publieront la nouvelle version dans leur sélecteur. Tu n'as souvent rien d'autre à faire qu'à vérifier que la version affichée passe bien à la version publiée le 21 octobre.
Si tu gères ton serveur (VPS, dédié, Docker) :
- Dès que la version du 21 octobre 2026 est disponible sur php.net, installe-la. Si tu utilises les paquets de ta distribution, c'est un simple
apt update && apt upgrade(ou l'équivalent) une fois le paquet publié. Si tu utilises Docker, change le tag de ton image (php:8.3-fpmdevient la version corrigée) et reconstruis le conteneur. - Redémarre PHP-FPM après la mise à jour, sinon le processus garde l'ancien code en mémoire :
sudo systemctl restart php8.3-fpm
Adapte 8.3 à ta version. Sous Apache avec mod_php, redémarre Apache.
- Vérifie ensuite que la version affichée par
php -vou par phpinfo() correspond bien à la version publiée le 21 octobre.
Si tu es sous PHP 8.1 ou plus ancien : il n'y aura pas de correctif officiel. Ta seule vraie sortie est de migrer vers une branche maintenue (8.2 à 8.5). En attendant la migration, la mesure temporaire ci-dessous peut réduire le risque, mais elle ne remplace pas la mise à jour.
Enfin, masque la version que ton serveur annonce. Dans ton php.ini :
expose_php = Off
À recharger après un redémarrage de PHP-FPM. C'est une bonne hygiène, mais sois clair avec toi-même : cacher la version ne corrige rien. C'est du bruit en moins pour un attaquant, pas un correctif.
La mesure temporaire : désactiver session.upload_progress
Les chercheurs qui ont travaillé sur « php2shell » — le nom a été évoqué publiquement par Kirill Firsov — pointent vers la fonction Session Upload Progress de PHP, une option de la couche session activée par défaut. En attendant le correctif, ou si tu es coincé sur une version non maintenue, tu peux la désactiver.
Dans le php.ini utilisé par ton serveur web (celui de PHP-FPM ou d'Apache, pas celui de la CLI) :
session.upload_progress.enabled = Off
Puis recharge PHP-FPM. Sous Debian ou Ubuntu, le plus propre est de créer un fichier dédié (par exemple 99-php2shell.ini) dans le dossier conf.d de PHP-FPM et de recharger le service.
Deux limites à connaître : d'une part, les barres de progression d'upload qui s'appuient sur cette fonction ne marcheront plus ; d'autre part, l'équipe PHP n'a pas confirmé officiellement cette piste. C'est une mesure d'attente recommandée par les chercheurs, pas une garantie. La mise à jour reste l'action principale.
Le prompt à coller dans ton agent
Si tu travailles avec Cursor, Claude Code ou un autre agent, colle ce prompt et adapte la description de ton projet :
Audite la configuration PHP de mon projet [Laravel / WordPress / app maison] déployé sur [VPS / Docker / hébergeur].
1. Détermine la version de PHP réellement exécutée côté serveur, pas seulement la version CLI : `php -v`, le tag de l'image Docker si je déploie en conteneur, ou le panneau de l'hébergeur.
2. Si la version est antérieure à la version publiée le 21 octobre 2026 sur php.net, propose la commande ou le changement de tag Docker exact pour passer à la version corrigée, puis la commande pour redémarrer PHP-FPM.
3. Si je suis sous PHP 8.1 ou plus ancien, propose un plan de migration vers une branche maintenue (8.2 à 8.5) et liste les points de compatibilité à vérifier pour mon code.
4. Ajoute `expose_php = Off` dans le php.ini du serveur web, et vérifie que `session.upload_progress.enabled` est bien sur `Off` tant que la mise à jour n'est pas appliquée.
5. Vérifie ensuite que la version affichée par phpinfo() côté web correspond bien à la version corrigée, et que PHP-FPM a bien été redémarré.
Relis les commandes avant de les exécuter : le prompt te donne la démarche, pas un feu vert automatique.
Pourquoi cacher ta version ne corrige rien
expose_php = Off retire l'en-tête X-Powered-By: PHP/8.3.7 de tes réponses HTTP. C'est utile : un attaquant qui scanne des milliers de sites repère plus vite les versions connues vulnérables. Mais un attaquant qui te cible directement peut deviner ta version autrement : un comportement d'erreur, une fonctionnalité, une empreinte de session. La version masquée, c'est de la friction, pas une protection. Le seul vrai correctif reste la mise à jour. Pour aller plus loin sur ce que ton serveur annonce, on a écrit un guide sur les en-têtes de sécurité et la CSP.
Vérifier ton site avec Rustine
Le scan rapide gratuit de Rustine lit la version de PHP que ton site annonce dans l'en-tête X-Powered-By et signale les versions touchées par ces deux failles. Si PHP est détecté mais que sa version est masquée, Rustine te rappelle simplement de la vérifier toi-même avec les méthodes ci-dessus. Tu peux tester ton site sur rustine.io.
Questions fréquentes
Je ne sais pas quelle version de PHP tourne sur mon serveur, je fais quoi ?
Commence par le panneau de ton hébergeur, puis php -v en SSH si tu y as accès. Si tu es en Docker, regarde le tag de ton image. La version qui compte est celle qui exécute ton site, pas forcément celle de la ligne de commande.
Mon hébergeur mutualisé va-t-il corriger automatiquement ?
Souvent oui, mais pas toujours. Vérifie la version affichée dans ton panneau après le 21 octobre et consulte la page de statut de ton hébergeur. Si la version ne bouge pas, ouvre un ticket.
Je suis sous PHP 7 ou PHP 5, je suis touché ?
L'idée que PHP 5 et PHP 7 seraient touchés n'est pas vérifiée. Ce qui est sûr : PHP 8.1 et plus ancien ne sont plus maintenus et ne recevront pas de correctif. Que la faille te touche ou non, la bonne décision est la même : migrer vers une branche maintenue.
C'est quoi, une exécution de code à distance ?
C'est la possibilité pour un attaquant d'exécuter ses propres commandes sur ton serveur à distance, sans avoir tes identifiants. C'est l'un des types de failles les plus graves, d'où la note de 9,2 sur 10.
Le correctif est déjà disponible ?
Il est publié le 21 octobre 2026 à 14 h UTC (16 h à Paris). Vérifie sur php.net, puis dans les paquets de ta distribution ou le registre de tes images Docker : il faut parfois quelques heures pour que tout se propage.