Le 21 octobre 2026, l'équipe de PHP a publié en urgence les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger deux failles notées 9,2 sur 10, surnommées PHP2Shell (CVE-2026-109618 et CVE-2026-109619). Elles permettent à un inconnu de prendre la main sur un serveur avec une seule requête, sans mot de passe, avant même que WordPress ou votre site ait chargé une ligne de code. Les grands hébergeurs ont corrigé leurs serveurs dans la semaine. Si votre site tourne sur une version de PHP plus ancienne que 8.2, il n'existe pas de correctif officiel : c'est là que se trouve le vrai risque.
Ce qui s'est passé, en clair
PHP est le langage qui fait tourner la grande majorité des sites de petites entreprises : WordPress, PrestaShop, Joomla, et beaucoup de sites faits sur mesure. Quand un visiteur ouvre une page, le serveur de votre hébergeur exécute PHP pour la fabriquer.
Les deux failles se situent dans PHP lui-même, pas dans votre site. L'une touche la façon dont PHP gère un manque de mémoire pendant la réception d'un formulaire, l'autre la façon dont il nettoie ce qui reste d'une requête avant de passer à la suivante. Dans les deux cas, une requête fabriquée exprès permet d'exécuter n'importe quel programme sur le serveur.
La chronologie est inhabituelle, et c'est elle qui explique la précipitation des hébergeurs :
- le 17 octobre, Amazon repère déjà des tentatives d'exploitation, quatre jours avant l'annonce publique ;
- le 20 octobre, PHP annonce une mise à jour de sécurité pour le lendemain ;
- le 21 octobre, les correctifs sont publiés, et les premières attaques sont signalées le jour même ;
- le 23 octobre, une troisième faille (CVE-2026-115560) est annoncée, sans correctif immédiat, avec un réglage provisoire à appliquer ;
- le 26 octobre, l'agence américaine de cybersécurité ajoute les deux failles à sa liste des vulnérabilités activement exploitées.
Votre site est-il concerné ?
Tout serveur qui exécute PHP pour répondre à des visiteurs est concerné, quelle que soit la façon dont PHP y est installé. Ce qui compte, c'est la version de PHP utilisée par votre hébergement.
| Version de PHP de votre site | Situation |
|---|---|
| 8.2, 8.3, 8.4 ou 8.5 | corrigée si l'hébergeur a installé la mise à jour d'octobre |
| 8.0 ou 8.1 | aucune version officielle corrigée ; protégée seulement si l'hébergeur a appliqué lui-même un correctif |
| 7.4 et plus ancienne | même situation, et souvent bien d'autres failles non corrigées depuis des années |
La version de PHP se trouve dans l'espace client de l'hébergeur, généralement dans la rubrique de l'hébergement web, ou dans WordPress sous Outils, puis Santé du site, puis l'onglet Infos et la section Serveur.
Mettre WordPress et ses extensions à jour est une bonne habitude, mais ne règle rien ici. La faille est en dessous, dans le moteur qui fait tourner WordPress.
Ce qu'ont fait les hébergeurs
Sur un hébergement mutualisé (le cas de la plupart des sites vitrines), c'est l'hébergeur qui installe PHP et le met à jour pour tous ses clients. D'après leurs communications, les grands hébergeurs français ont réagi vite : IONOS a annoncé dès le 22 octobre que ses hébergements étaient protégés, OVHcloud a étalé ses mises à jour sur plusieurs jours en prévenant de ralentissements possibles, o2switch a recompilé PHP dès le 21.
Une mise à jour faite en urgence, sur des milliers de serveurs à la fois, n'est jamais tout à fait sans effet. Deux choses peuvent arriver à un site qui fonctionnait la veille :
- un ralentissement ou une coupure de quelques minutes pendant le redémarrage des serveurs, sans conséquence durable ;
- une erreur nouvelle, plus rare mais réelle : les versions 8.4.27 et 8.5.12 publiées le 21 octobre contenaient elles-mêmes un défaut qui pouvait faire planter certaines pages manipulant des données XML. Il a été corrigé le lendemain dans le code de PHP, mais il faut que l'hébergeur installe à son tour la version suivante.
Enfin, un hébergeur peut décider, pour protéger ses serveurs, de faire passer d'office vers une version récente les sites restés sur une très vieille version de PHP. Un vieux site WordPress jamais mis à jour peut alors afficher, du jour au lendemain, le message « Il y a eu une erreur critique sur ce site ».
Ce qu'il faut vérifier, dans l'ordre
- La version de PHP : 8.2 au minimum, idéalement 8.3 ou 8.4. Si elle est plus ancienne, c'est la priorité absolue, avant toute autre chose.
- La confirmation de l'hébergeur : sur un mutualisé, un message de sa part ou une page d'état indique si la mise à jour d'octobre est installée. Sur un serveur dédié ou un VPS, c'est à vous (ou à votre prestataire) de l'installer, puis de redémarrer PHP : tant que les processus tournent, l'ancienne version reste en mémoire.
- Le bon fonctionnement du site : formulaire de contact, panier, espace client. Un formulaire qui n'envoie plus rien depuis le 21 octobre est un signe à ne pas ignorer.
- Les signes d'intrusion : nouveaux comptes administrateurs, fichiers PHP inconnus dans le dossier des images, redirections vers des sites étrangers. Les attaques ayant commencé avant l'annonce, la vérification doit remonter au 17 octobre au moins. La marche à suivre en cas de doute est détaillée dans site WordPress piraté : les gestes des premières heures.
Le cas des vieux sites
Le vrai danger de cette faille n'est pas pour les sites à jour, corrigés en quelques jours sans que leurs propriétaires s'en aperçoivent. Il est pour les sites qui tournent encore sous PHP 7.4 ou 8.0 parce qu'un thème ou une extension ancienne refuse de fonctionner avec une version plus récente.
Pour ces sites, il n'y a que deux issues : mettre le site à niveau pour qu'il accepte un PHP récent (mettre à jour le thème, remplacer les extensions abandonnées, corriger le code), ou le reconstruire. La bonne réponse dépend de l'état du site, et elle est discutée dans refonte ou repartir de zéro.
Une échéance arrive en plus très vite : PHP 8.2 cesse d'être suivi le 31 décembre 2026. Un site qui vient tout juste d'y passer devra donc bouger de nouveau dans deux mois.
Questions fréquentes
Mon site est hébergé chez OVH ou IONOS, dois-je faire quelque chose ?
Sur un hébergement mutualisé, l'hébergeur a mis PHP à jour pour vous. Il vous reste deux vérifications : que votre site utilise bien une version encore suivie (8.2 ou plus récente) et qu'il fonctionne normalement depuis la mise à jour. Sur un VPS ou un serveur dédié, la mise à jour vous revient.
Un site vitrine sans formulaire est-il concerné ?
Oui, s'il fonctionne avec PHP, ce qui est le cas de tout site WordPress. La faille se déclenche avant que la page soit fabriquée, il n'y a pas besoin d'un formulaire visible sur le site. Un site entièrement statique, en HTML seul, n'est pas concerné.
Masquer les erreurs PHP ou installer une extension de sécurité suffit-il ?
Non. Les extensions de sécurité de WordPress interviennent après le démarrage de PHP, la faille agit avant. Seule la mise à jour de PHP corrige le problème ; les réglages provisoires publiés par l'équipe de PHP réduisent le risque sans le supprimer.
Comment savoir si mon site a été attaqué ?
Les signes les plus courants sont un compte administrateur inconnu, des fichiers PHP récents dans wp-content/uploads, des pages en langue étrangère qui apparaissent dans Google ou un avertissement de sécurité dans Search Console. L'absence de ces signes n'est pas une preuve, mais leur présence en est une.
