Le 21 octobre 2026, l'équipe de PHP a publié en urgence quatre versions correctives pour deux failles notées 9,2 sur 10. Elles permettent à n'importe qui, sans compte ni mot de passe, d'exécuter ses propres commandes sur un serveur web. Les détails avaient fuité la veille, avant même que les correctifs soient prêts.
PHP fait tourner WordPress, WooCommerce, PrestaShop, Magento et une bonne partie des sites de petites entreprises. Si vous avez un site, la question n'est pas de savoir si c'est grave, mais si le vôtre a été mis à jour.
Ce qui s'est passé
Les deux failles portent les identifiants CVE-2026-109618 et CVE-2026-109619. Les chercheurs les ont surnommées PHP2Shell.
- 20 octobre : PHP annonce une publication de sécurité critique pour le lendemain. Le même jour, des détails techniques circulent déjà sur les réseaux sociaux.
- 21 octobre : sortie de PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Dans les heures qui suivent, la société watchTowr observe des tentatives d'exploitation sur ses serveurs pièges.
Le point qui rend ces failles sérieuses : elles sont dans PHP lui-même, pas dans WordPress ou dans une extension. Un site au code parfaitement propre est exposé dès lors que la version de PHP qui le fait tourner n'est pas corrigée. Et l'équipe de PHP le dit sans détour : aucun réglage ne protège complètement, seule la mise à jour le fait.
Êtes-vous concerné ?
Tout serveur qui exécute PHP pour répondre à des visiteurs est dans le périmètre, quelle que soit la façon dont PHP est branché au serveur web (PHP-FPM, Apache, LiteSpeed…). Tout dépend ensuite de la version :
| Version de PHP | Situation |
|---|---|
| 8.5, 8.4, 8.3, 8.2 | Corrigées par 8.5.12, 8.4.27, 8.3.36 et 8.2.35. En dessous, vulnérable. |
| 8.1, 8.0, 7.4 | Vulnérables, sans nouvelle version officielle. Seuls des correctifs repris par certaines distributions Linux ou prestataires les protègent. |
| 7.3 et antérieures, PHP 5 | Vulnérables, et aucun correctif n'existe. |
Une précision qui compte pour la suite : PHP 8.2 n'est plus maintenu que jusqu'au 31 décembre 2026. Le mettre à jour aujourd'hui règle l'urgence, mais il faudra changer de version dans deux mois.
Comment le vérifier
Sur WordPress, allez dans Outils → Santé du site → Informations, rubrique Serveur : la version de PHP y est affichée.
Sur un hébergement mutualisé (OVH, IONOS, o2switch, Hostinger…), la version se choisit dans l'espace client de l'hébergeur. L'hébergeur installe les correctifs, mais pas toujours sur les anciennes versions : un site resté en PHP 7.4 parce que « ça marchait » est précisément celui qui n'en recevra pas.
Sur un serveur que vous administrez, php -v donne la version en ligne de
commande — qui n'est pas toujours celle qui sert le site. La version réellement
utilisée par le serveur web se lit dans sa configuration ou avec une page
phpinfo() temporaire, à supprimer aussitôt après.
Ce qu'il faut faire
- Mettre à jour PHP vers la dernière version de sa branche : 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 au minimum.
- Redémarrer PHP après la mise à jour. Les processus déjà lancés continuent d'exécuter l'ancienne version tant qu'on ne les relance pas.
- Pour un site bloqué en 8.1 ou plus ancien, c'est le moment de le faire passer sur une version maintenue. Un site qui ne supporte pas PHP 8.3 a souvent une extension ou un thème abandonné : autant le savoir maintenant.
- Si le site ne peut pas être mis à jour tout de suite, le retirer d'Internet le temps de le faire plutôt que de le laisser exposé.
- Regarder ce qui a changé depuis le 20 octobre : nouveaux comptes administrateurs, fichiers PHP modifiés ou ajoutés, tâches planifiées inconnues. Une mise à jour ferme la porte ; elle ne fait pas sortir quelqu'un qui serait déjà entré.
Si vous ne savez pas qui s'occupe de votre site
C'est le cas le plus fréquent, et le plus risqué : le site a été fait il y a quelques années, il fonctionne, et plus personne ne regarde ce qui tourne dessous. Ces failles en sont la démonstration — rien n'était visible à l'écran.
Nous pouvons vérifier la version de PHP de votre site, appliquer la mise à jour et contrôler qu'il n'y a pas eu d'intrusion, à distance dans la plupart des cas. Et si vous voulez que ce genre de vérification soit faite sans attendre la prochaine alerte, c'est le rôle de la gestion de serveurs. Pour une vérification ponctuelle : écrivez-nous.
Versions et dates vérifiées sur php.net et dans l'avis de watchTowr au 26 octobre 2026. La situation évolue : une troisième faille, plus limitée (CVE-2026-115560), a été signalée le 23 octobre et sera corrigée dans la prochaine version de PHP.