php2shell : la faille PHP critique, comment vérifier et corriger

Le 21 octobre 2026, l'équipe qui développe PHP a publié en urgence des correctifs pour deux failles critiques, surnommées php2shell. Elles permettent à un attaquant anonyme d'exécuter du code sur le serveur qui héberge votre site, sans identifiant ni mot de passe. Ce n'est pas un plugin qui est en cause, c'est PHP lui-même : le langage qui fait tourner WordPress, PrestaShop, Nextcloud, la plupart des intranets et une grande partie des applications web de PME.

#1. Ce qui se passe, en cinq points

• Deux failles critiques : CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 (CVSS v4). Elles permettent une exécution de code à distance sans authentification, avec les droits du processus qui sert le site.
• Les causes : la première survient quand PHP manque de mémoire au milieu d'une requête et traite ensuite comme valides des données à moitié initialisées. La seconde vient d'un état interne réutilisé par une requête suivante alors que sa mémoire a été libérée.
• Qui est touché : toute installation PHP qui répond à des requêtes web (PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed). Le cas jugé le plus exposé est mod_php, où l'attaque a été démontrée avant même que le code du site ne s'exécute.
• Les versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les versions 8.1 et antérieures ne sont plus maintenues ; des correctifs sous forme de code source existent pour 7.4, 8.0 et 8.1.
• L'urgence : les identifiants des failles ont circulé avant la date prévue et la publication a été avancée. L'agence américaine de cybersécurité (CISA) demande de corriger immédiatement. Des preuves de concept circulent et des éditeurs de sécurité signalent de premières tentatives d'exploitation, même si le CISA n'en avait pas constaté au moment de son alerte.

Mutualisé, dédié, VPS ou conteneur : tout le monde est concerné. Seul change celui qui doit faire la mise à jour.

#2. Comment savoir si je suis concerné

Une seule question : quelle version de PHP sert votre site ? Si elle est inférieure à la version corrigée de sa branche (8.3.35 ou moins pour la branche 8.3, par exemple), vous êtes vulnérable.

Vérification rapide depuis l'extérieur. Beaucoup de serveurs annoncent leur version de PHP à chaque visite. Notre détecteur app2shell gratuit la lit, sans rien envoyer de malveillant, et vous dit si elle est corrigée. Si le serveur masque sa version, l'outil ne peut pas conclure : passez aux vérifications ci-dessous.

Hébergement mutualisé. La version se lit dans l'espace client de l'hébergeur, rubrique configuration de l'hébergement web. C'est l'hébergeur qui installe PHP, donc lui qui corrige. Beaucoup le font vite sur une faille de ce niveau, mais ne le supposez pas : vérifiez que le numéro a changé, ou demandez-le par écrit au support. Dans WordPress, la version s'affiche aussi dans Outils > Santé du site > Infos > Serveur.

Serveur dédié ou VPS. En SSH :

php -v

Cette commande donne la version en ligne de commande, qui n'est pas toujours celle qui sert le site : vérifiez aussi le service web (par exemple php-fpm8.3 -v sur Debian ou Ubuntu). Sur une distribution Linux, le numéro peut rester ancien alors que le correctif est appliqué, car les distributions intègrent la correction dans leur propre numérotation de paquet : consultez le bulletin de sécurité de votre distribution. Si vous installez PHP depuis un dépôt tiers, vérifiez qu'il a publié la mise à jour, l'équipe PHP ayant prévenu qu'au moins un dépôt communautaire très utilisé ne l'aurait pas le jour même.

Conteneurs Docker. Une image ne se met pas à jour toute seule. Il faut reconstruire l'image à partir d'une base PHP corrigée, puis redéployer. Redémarrer l'ancien conteneur ne change rien.

Logiciels qui embarquent PHP. Certains outils métier ou boîtiers intègrent leur propre PHP sans que ce soit visible : demandez à chaque éditeur s'il est concerné.

#3. Que faire maintenant

1. Sauvegardez d'abord fichiers et base de données, hors du serveur. Une mise à jour de PHP peut casser une vieille extension.
2. Mettez à jour vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 selon votre branche, ou vers le paquet corrigé de votre distribution.
3. Redémarrez PHP (PHP-FPM ou Apache) : tant que les anciens processus tournent, l'ancienne version reste en mémoire.
4. Vérifiez que la version servie par le site a bien changé.
5. En PHP 8.1 ou plus ancien, migrez vers une version maintenue. Si la mise à jour est impossible dans l'immédiat, le CISA recommande de retirer le système d'Internet en attendant.

#En attendant la mise à jour

Si vous ne pouvez pas mettre à jour tout de suite, une mesure réduit l'exposition à la seconde faille : désactiver le suivi de progression des envois dans php.ini ou dans le pool PHP-FPM, puis redémarrer tous les processus.

session.upload_progress.enabled = 0

Un ini_set() dans le code ou un fichier .user.ini ne suffit pas. Ce réglage bloque les chemins d'attaque connus, pas toutes les variantes, et ne remplace pas la mise à jour.

#Chercher des signes de compromission

Le correctif ferme la porte pour l'avenir, il ne fait rien contre une intrusion déjà réalisée. Sur les serveurs restés exposés depuis le 21 octobre, vérifiez :

• des processus inconnus, en particulier un processus PHP qui lance un shell ou télécharge des outils ;
• des fichiers récents dans le dossier du site, surtout des fichiers PHP aux noms aléatoires ou dans les dossiers d'envoi (wp-content/uploads par exemple) ;
• une charge processeur anormale, qui peut trahir un mineur de cryptomonnaie ;
• des comptes administrateur créés sans votre accord, dans l'application ou sur le serveur ;
• des tâches planifiées ou des connexions sortantes que vous ne reconnaissez pas.

Un seul de ces signes justifie un diagnostic. L'absence de signe visible ne prouve rien.

#4. Questions fréquentes

#Mon site WordPress est-il concerné ?

Oui, s'il tourne sur une version de PHP non corrigée. La faille est dans PHP, pas dans WordPress : mettre à jour WordPress et ses extensions ne suffit pas.

#Mon hébergeur s'en occupe-t-il ?

Sur un mutualisé, oui, c'est à lui de mettre PHP à jour. Sur un dédié, un VPS ou un conteneur, c'est à vous ou à votre prestataire. Dans tous les cas, vérifiez la version réellement servie.

#Que faire si j'ai été piraté ?

Mettre à jour ne suffit pas : une porte dérobée déjà déposée resterait en place. Isolez le site, faites identifier le point d'entrée et toutes les portes dérobées, restaurez une version saine, changez tous les secrets (mots de passe, clés d'API, accès base de données, FTP et SSH), puis durcissez la configuration. Si des données personnelles ont pu être exposées, le RGPD impose de notifier la CNIL dans les 72 heures. Notre guide de récupération d'un site piraté détaille chaque étape.

#Un pare-feu applicatif suffit-il ?

Non. Il peut bloquer une partie des attaques en attendant le correctif, mais seulement pour le trafic qui passe par lui. La mise à jour reste la seule solution complète.

#Faut-il tester la faille sur mon propre site ?

Non. Les codes d'exploitation qui circulent ne sont pas vérifiés et peuvent contenir eux-mêmes des logiciels malveillants. Vérifier la version de PHP suffit.

#5. Comment M-KIS peut vous aider

Si votre site est déjà compromis, notre offre de secours de site piraté prend en charge le diagnostic, le nettoyage et la remise en ligne sécurisée. Quand l'intrusion touche le serveur lui-même, elle relève de notre intervention sur serveur infecté, dans le cadre de notre réponse à incident.

Pour ne plus gérer ce type d'alerte dans l'urgence, notre infogérance prend en charge les mises à jour de sécurité de vos serveurs, et notre SOC managé surveille les comportements suspects. Pour toute question, écrivez-nous : nous répondons rapidement par mail.