La faille PHP2Shell permet à un attaquant d’exécuter du code à distance, sans authentification, sur un serveur web qui fait tourner PHP. Si votre site WordPress, votre extranet ou votre outil de ticketing repose sur PHP, la réponse est simple : faites appliquer la mise à jour PHP aujourd’hui, puis vérifiez que personne n’est entré avant.
Deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, ont été corrigées en urgence par l’équipe PHP. Le correctif a été publié un jour plus tôt que prévu, après une fuite des détails techniques. L’agence américaine CISA demande de passer immédiatement en PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, et de déconnecter les systèmes qui ne peuvent pas être mis à jour.
Faille PHP2Shell : pourquoi votre PME est concernée
PHP n’est pas un logiciel que l’on « installe » consciemment. C’est le moteur qui exécute WordPress, Drupal, Moodle, GLPI, Nextcloud, de nombreux ERP web et une bonne partie des interfaces d’administration d’équipements réseau. Le NCSC britannique précise que toutes les versions de PHP peuvent être affectées : il ne suffit donc pas de chercher les vieux serveurs oubliés.
Les deux failles touchent la gestion de la mémoire et des erreurs, une partie du code que pratiquement chaque requête traverse. Un attaquant provoque une saturation mémoire, ce qui laisse des données internes dans un état incohérent ; il s’en sert ensuite pour prendre la main sur le processus PHP. Selon la PHP Foundation, tous les modes d’exécution courants sont exposés, y compris PHP-FPM, Apache avec mod_php et LiteSpeed. La même mécanique peut aussi servir à lire la mémoire du processus, où se trouvent souvent des mots de passe de base de données et des clés d’API.
Point important pour une PME : le code de votre site peut être parfaitement à jour et sécurisé, la faille se situe en dessous, dans le langage lui-même. Mettre à jour vos extensions WordPress ne vous protège pas.
Ce que l’on sait de l’exploitation
Les failles ont été découvertes par des chercheurs de Wiz, Calif et OpenAI, avec l’aide de modèles d’IA de pointe capables d’enchaîner les étapes d’exploitation. L’analyse technique de Wiz indique que d’autres variantes du même problème existent, ce qui laisse prévoir de nouveaux correctifs dans les semaines à venir.
Au moment de son alerte, la CISA n’avait pas encore observé d’exploitation réussie. Plusieurs éditeurs de sécurité signalent en revanche des tentatives d’exploitation sur leurs capteurs dès la publication du correctif, et des preuves de concept circulent publiquement. Certains organismes publics ont préféré mettre leur site hors ligne par précaution. Le délai entre la publication d’un correctif et les premières attaques de masse se compte désormais en heures, pas en semaines.
Où se cache PHP dans votre système d’information
La difficulté n’est pas d’appliquer le correctif, c’est de savoir où il faut l’appliquer. Dans une PME, PHP se trouve généralement à trois endroits :
- Le site vitrine et la boutique en ligne, souvent chez un hébergeur mutualisé : c’est lui qui met PHP à jour, pas vous.
- Les applications internes installées sur un serveur maison ou une machine virtuelle : intranet, GLPI, outil de devis, wiki, Nextcloud.
- Les équipements et logiciels qui embarquent PHP sans le dire : NAS, interfaces d’administration, solutions métier. Le NCSC néerlandais tient un inventaire des produits concernés, mis à jour au fil des annonces des éditeurs.
Que faire maintenant
- Demandez par écrit à votre hébergeur et à votre infogérant la version de PHP en production sur chacun de vos sites, et la date à laquelle la version corrigée sera déployée.
- Identifiez les serveurs et équipements internes qui exécutent PHP, en commençant par ceux accessibles depuis Internet, et croisez la liste avec l’inventaire du NCSC néerlandais.
- Appliquez la version corrigée de votre branche (8.5.12, 8.4.27, 8.3.36 ou 8.2.35), puis redémarrez PHP-FPM ou Apache et vérifiez la version réellement servie.
- Retirez d’Internet les applications bloquées en PHP 8.1 ou plus ancien jusqu’à leur migration : aucune version corrigée n’existe pour elles.
- Recherchez les traces d’intrusion sur les serveurs exposés avant le correctif (fichiers PHP récents dans les dossiers d’envoi, processus PHP qui lancent un shell, nouveaux comptes administrateurs), puis renouvelez les mots de passe et clés stockés sur ces serveurs.
Ce type d’attaque, qui frappe des milliers de serveurs en quelques heures, se détecte et se contient avec une surveillance continue : découvrez notre SOC managé 24/7 pour PME et ETI.
Si vous découvrez des fichiers suspects sur votre site, notre plan d’urgence face à une backdoor WordPress détaille les étapes de nettoyage. Pour la méthode de priorisation des correctifs, voir aussi notre article sur la gestion des correctifs face à l’inflation des CVE.
Ce qu’il faut retenir
- PHP2Shell touche le moteur PHP lui-même : un site à jour côté CMS reste vulnérable.
- Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
- Votre hébergeur doit confirmer le déploiement : ne le supposez pas.
- PHP 8.1 et antérieur n’a pas de correctif : isolez ces applications.
- Après la mise à jour, cherchez les signes d’une intrusion antérieure.