Le 21 octobre 2026, l’équipe de PHP a publié en urgence de nouvelles versions de son moteur pour corriger deux failles critiques, vite baptisées « PHP2Shell ». Leur gravité est rare : une simple requête envoyée à un site non corrigé peut suffire à y exécuter du code, sans mot de passe ni compte. Deux jours plus tard, une troisième faille, liée à la même fonction, était annoncée.
Comme tous les sites que je développe et que je maintiens tournent sous PHP, la première question a été simple : mes sites, et ceux de mes clients, sont-ils exposés ? Voici comment j’ai vérifié.
Ce qu’il faut retenir de PHP2Shell
Les deux failles, référencées CVE-2026-109618 et CVE-2026-109619, ont reçu une note de 9,2 sur 10. Elles se situent dans PHP lui-même, pas dans un CMS ou une extension : mettre à jour WordPress, PrestaShop ou un module ne sert à rien. Seule la mise à jour de PHP corrige le problème.
Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les versions 8.1 et antérieures n’ont pas de nouvelle version officielle : un site qui y tourne encore doit migrer. Et des tentatives d’attaque ont été observées dès la publication des correctifs.
La troisième faille, CVE-2026-115560, est d’une autre nature : elle ne concerne que des applications qui combinent un réglage de sessions particulier et une fonction appelée « progression d’envoi en session », active par défaut. PHP recommande de désactiver cette fonction en attendant le correctif.
Étape 1 : savoir où tourne chaque site
La réponse dépend d’abord de qui gère PHP. Sur un serveur dédié, c’est vous. Sur un hébergement mutualisé, c’est l’hébergeur qui installe les versions de PHP ; le propriétaire du site choisit seulement quelle branche utiliser.
J’ai donc commencé par lister chaque site avec son hébergement et sa branche de PHP. Mes sites sont en hébergement mutualisé : la correction dépendait d’abord de l’hébergeur, mais encore fallait-il le vérifier.
Étape 2 : un script d’une ligne, déposé puis supprimé
Le panneau d’un hébergeur affiche la branche choisie, mais pas toujours la version exacte réellement en service. Pour en avoir le cœur net, j’ai écrit un script d’une seule ligne qui affiche deux informations : la version précise de PHP, et l’état de la progression d’envoi en session.
Je l’ai déposé sur chaque site sous un nom de fichier aléatoire, ouvert dans le navigateur, noté le résultat, puis supprimé aussitôt. Ce dernier point compte : un fichier de diagnostic oublié sur un serveur renseigne aussi les attaquants.
Étape 3 : comparer et conclure
Il reste à comparer la version affichée avec la version corrigée de sa branche. Pour mes sites, les relevés indiquaient que l’hébergeur avait fait le nécessaire sur son infrastructure. Sur un hébergement mutualisé, c’est le scénario attendu, mais il vaut mieux le constater que le supposer.
Une précaution tout de même : certains hébergeurs appliquent un correctif sans changer le numéro de version. En cas de doute, la bonne démarche est de demander une confirmation écrite au support.
Étape 4 : vérifier son propre code pour la troisième faille
Pour la troisième faille, la question ne porte plus seulement sur PHP, mais aussi sur le code des applications. Elle suppose une application qui change en cours d’exécution la façon dont ses sessions sont enregistrées, avant de les ouvrir.
J’ai donc relu les applications que j’ai écrites. Aucune ne modifie ce réglage, et aucune n’utilise la progression d’envoi de PHP : quand une barre de progression est nécessaire, comme pour l’import de vidéos de la photothèque familiale, le fichier est découpé en morceaux par le navigateur. Mes sites ne sont donc pas exposés par ce chemin.
Désactiver la fonction reste une précaution raisonnable quand on n’en a pas l’usage. Le script d’une ligne sert alors une seconde fois : après le changement, il permet de vérifier que le réglage a réellement été pris en compte.
Ce que j’en retiens
- Savoir où tourne chaque site et qui en gère PHP : c’est ce qui permet de répondre en minutes, et non en jours.
- Rester sur une branche maintenue : les sites encore en PHP 8.1 ou plus ancien n’ont pas reçu de correctif officiel.
- Vérifier plutôt que supposer, avec un contrôle simple, puis ne rien laisser traîner sur le serveur.
- Relire son code quand une faille dépend de la façon dont l’application utilise PHP.
Vous ne savez pas sur quelle version tourne votre site ?
Si personne ne suit la version de PHP de votre site, ou si vous n’êtes pas sûr qu’il ait été corrigé, je peux faire la vérification pour vous et, si besoin, organiser la mise à jour. C’est aussi le rôle d’un contrat de maintenance.