Le 21 octobre 2026, l’équipe de PHP a publié des correctifs d’urgence pour deux failles critiques, surnommées « PHP2Shell ». PHP est le langage sur lequel tourne la grande majorité des sites, WordPress compris. Ces failles concernent donc votre site, même si vous n’avez rien touché. Voici ce qu’elles sont, ce qu’elles permettent et, surtout, ce qu’il faut vérifier dès maintenant, sans jargon.
Point de situation au 22 octobre 2026. Les correctifs sont disponibles, mais leur déploiement chez les hébergeurs est encore en cours. Cet article sera complété si la situation évolue.
L’essentiel en quelques lignes
- Deux failles dans PHP lui-même, notées 9,2 sur 10 en gravité.
- Dans certaines conditions, un attaquant sans identifiant pourrait exécuter du code sur le serveur à distance.
- Mettre à jour WordPress ne suffit pas : c’est le serveur, donc votre hébergeur, qui doit mettre PHP à jour.
- Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
- Des tentatives d’attaque ont été signalées avant la publication des correctifs.
PHP, c’est quoi, et pourquoi ça vous concerne ?
Quand quelqu’un ouvre votre site, un programme tourne sur le serveur pour construire la page : c’est PHP. WordPress, WooCommerce, PrestaShop, Joomla ou Drupal sont tous écrits en PHP. On peut le voir comme le moteur d’une voiture : vous conduisez WordPress, mais c’est PHP qui fait avancer l’ensemble. Une faille dans le moteur touche donc toutes les voitures qui l’utilisent, quelle que soit la marque.
Que s’est-il passé ?
Les failles avaient été signalées à l’équipe de PHP en août. Les correctifs ont été publiés le 21 octobre à 14 h (UTC), un jour plus tôt que prévu, après des fuites d’informations. Dans l’intervalle, plusieurs sociétés de sécurité (dont Cloudflare) ont signalé des tentatives d’exploitation avant même la publication des correctifs.
Les deux failles portent les références CVE-2026-109618 et CVE-2026-109619. PHP les a notées 9,2 sur 10, ce qui correspond à une gravité critique.
Comment ça fonctionne, en image
Les deux failles ont une origine commune. Quand PHP rencontre une erreur grave en plein travail (par exemple parce qu’il manque de mémoire), il s’arrête brutalement, sans avoir fini son « ménage ». Une partie de sa mémoire reste alors dans un état incohérent : des objets déjà jetés sont encore considérés comme valides.
Imaginez un cuisinier interrompu au milieu du service, qui laisse sur le plan de travail des ingrédients qu’il croit encore frais. Le suivant arrive, les utilise sans vérifier, et le plat est contaminé. Un attaquant peut provoquer cette situation exprès, puis profiter du désordre pour glisser ses propres instructions.
Le point inquiétant : le déclencheur connu est une simple requête d’envoi de données (le type utilisé par les formulaires et les téléversements de fichiers), que PHP traite avant même que WordPress ne se charge. Aucune connexion à votre site n’est nécessaire.
Quelles conséquences possibles ?
Si l’attaque réussit, l’attaquant peut faire exécuter du code sur le serveur avec les droits du site. Il pourrait alors modifier ou supprimer des pages, ajouter des comptes administrateurs, installer des fichiers malveillants, rediriger vos visiteurs vers d’autres sites ou lire des informations sensibles présentes en mémoire. Le risque est donc réel, mais il dépend de la configuration du serveur et d’une attaque correctement menée.
Pourquoi mettre WordPress à jour ne protège pas
La faille est sous WordPress, pas dedans. L’équipe de sécurité de WordPress l’a précisé : aucune mise à jour de WordPress n’est requise ni prévue. Les mises à jour d’extensions, les plugins de sécurité et les extensions de maintenance n’y changent rien non plus, car l’attaque survient avant leur chargement. Le seul remède durable est la mise à jour de PHP sur le serveur.
Suis-je concerné ?
En pratique, oui, si votre site tourne sous PHP et que votre hébergeur n’a pas encore appliqué le correctif. Voici la situation selon la version :
- PHP 8.2, 8.3, 8.4, 8.5 : des versions corrigées existent (8.2.35, 8.3.36, 8.4.27, 8.5.12). Il faut qu’elles soient installées sur le serveur.
- PHP 8.1 et antérieures : l’équipe de PHP ne les maintient plus. Des correctifs minimaux existent pour certaines versions anciennes, mais ils doivent être appliqués par l’hébergeur. Il vaut mieux prévoir une migration.
- PHP 8.2 : corrigé aujourd’hui, mais cette branche ne recevra plus de correctifs de sécurité après le 31 décembre 2026. Visez PHP 8.3 ou plus récent.
Selon The Repository, plus d’un site WordPress sur trois utiliserait une version de PHP qui n’est plus corrigée. Ce n’est donc pas un cas marginal.
Que faire concrètement ?
1. Vérifier la version de PHP
Dans WordPress : Outils → Santé du site → Info → Serveur. Vous y verrez la version de PHP utilisée. Vous pouvez aussi la consulter dans l’espace client de votre hébergeur.
2. Interroger votre hébergeur, par écrit
Le numéro affiché ne suffit pas à conclure. Certains hébergeurs appliquent le correctif sans changer le numéro de version, d’autres affichent déjà la nouvelle version alors que leur déploiement n’est pas terminé. Demandez-leur clairement :
- le correctif des CVE-2026-109618 et CVE-2026-109619 est-il appliqué à mon site ?
- quelle version exacte de PHP s’exécute sur mon compte ?
- à quelle date le correctif a-t-il été ou sera-t-il déployé ?
Une réponse écrite vous protège aussi en cas de problème ultérieur.
3. Changer de version PHP avec précaution
Dans la plupart des espaces clients, vous pouvez choisir la version de PHP de votre site. Faites une sauvegarde avant, puis testez les pages principales, l’administration et les formulaires. Changer de version peut aussi réinitialiser certains réglages propres à la version, comme la taille maximale des fichiers que l’on peut téléverser : si un envoi échoue ensuite, c’est là qu’il faut regarder. Et ne comptez pas sur ce changement pour obtenir « la dernière version corrigée » : c’est l’hébergeur qui met à disposition les paquets corrigés.
4. Prévoir la migration si vous êtes en PHP 8.1 ou plus ancien
Vérifiez la compatibilité de votre thème et de vos extensions, testez sur une copie du site, puis basculez vers PHP 8.3 ou plus récent. Si votre thème est ancien, c’est peut-être aussi l’occasion de le moderniser.
5. Si vous gérez votre propre serveur
Installez les paquets PHP corrigés de votre distribution, puis redémarrez PHP (PHP-FPM ou Apache) pour que tous les processus utilisent la nouvelle version. Avec Docker, il faut reconstruire les conteneurs.
Et en attendant le correctif ?
Certaines protections temporaires existent, mais elles ne remplacent jamais la mise à jour :
- Un pare-feu applicatif en amont du site : Cloudflare a déployé des règles de protection pour tous ses clients, y compris en formule gratuite. C’est un palliatif, pas un correctif.
- Des réglages serveur de contournement, que seul l’hébergeur peut appliquer sur un hébergement mutualisé. Ils réduisent le risque sans le supprimer, et peuvent limiter certains téléversements de fichiers.
Sur un serveur que vous gérez et qui ne peut pas être corrigé, l’équipe de sécurité de WordPress recommande, pour les versions antérieures à PHP 8.2, de mettre le site hors ligne le temps de la migration.
Comment repérer une éventuelle intrusion
À ce stade, les sources consultées ne font pas état de compromissions massives confirmées, mais des tentatives ont bien été détectées. Quelques vérifications simples :
- la liste des utilisateurs administrateurs de WordPress (un compte inconnu est un signal d’alerte)
- les extensions installées, à la recherche d’extensions que vous n’avez pas ajoutées
- la présence de fichiers
.phpinhabituels, notamment dans le dossier des médias (wp-content/uploads), où il ne devrait normalement pas y en avoir - les pages indexées par Google : une recherche
site:votredomaine.frpeut révéler des pages que vous n’avez jamais créées - les alertes ou messages de votre hébergeur
En cas de doute : restaurez une sauvegarde antérieure, changez tous vos mots de passe (administration, hébergement, base de données) et demandez l’aide de votre hébergeur ou d’un professionnel.
Ce qu’on ne sait pas encore
Par honnêteté, voici ce qui reste incertain à l’heure où j’écris : le nombre réel de sites compromis (aucune exploitation réussie à grande échelle n’avait été confirmée par les autorités et les éditeurs de sécurité), l’ampleur exacte des attaques à venir, et l’état de déploiement du correctif chez chaque hébergeur, qui repose sur leurs propres annonces. Méfiez-vous aussi des « outils d’exploitation » qui circulent : le code peut être peu fiable, voire malveillant.
Ce que cette affaire rappelle
- Le choix de l’hébergeur compte. Sa réactivité face à une faille critique est un vrai critère : j’ai détaillé les points à comparer dans mon article sur le choix de l’hébergeur.
- Une version de PHP ancienne est un risque, et ce risque ne diminue pas avec le temps.
- Les sauvegardes sont indispensables. Elles sont ce qui permet de revenir en arrière après un incident.
- Garder la main sur ses accès. Au moment où il faut réagir, il vaut mieux être titulaire de son hébergement que dépendre d’un tiers.
Questions fréquentes
Mon site est-il piraté ?
Rien ne permet de l’affirmer. La faille crée un risque, pas forcément une intrusion. Les vérifications ci-dessus permettent de détecter les signes les plus courants.
Dois-je mettre mon site hors ligne ?
Pas systématiquement. L’équipe de sécurité de WordPress ne le recommande que pour les serveurs qui utilisent une version antérieure à PHP 8.2 et qui ne peuvent pas être corrigés rapidement. Pour un hébergement mutualisé, la démarche normale est d’obtenir la confirmation du correctif auprès de l’hébergeur.
Un plugin de sécurité me protège-t-il ?
Non, pas contre cette faille. L’attaque se produit au niveau de PHP, avant le chargement de WordPress et de ses extensions.
Dois-je changer mes mots de passe ?
Pas par principe, mais c’est recommandé au moindre doute d’intrusion. Il est de toute façon utile de vérifier que vos accès sont solides et que la double authentification est activée.
Cette faille concerne-t-elle seulement WordPress ?
Non. Elle concerne tout serveur qui héberge une application PHP : WordPress, mais aussi WooCommerce, PrestaShop, Joomla, Drupal ou tout site développé sur mesure en PHP.
En résumé
Les failles PHP2Shell sont sérieuses, mais des correctifs existent. Ce qui compte, c’est de vérifier la version de PHP de votre site, d’obtenir de votre hébergeur une confirmation écrite que le correctif est appliqué, de prévoir une migration si vous êtes sur une version ancienne et de garder des sauvegardes à jour. Il n’y a pas lieu de paniquer, mais il ne faut pas laisser traîner.
Vous n’êtes pas sûr de la version de PHP de votre site, ou vous souhaitez de l’aide pour la migration ? Contactez-moi, on regarde ensemble votre situation.
Cet article a une visée informative générale et reflète l’état des informations disponibles au 22 octobre 2026, susceptible d’évoluer. Il ne remplace pas l’avis de votre hébergeur ni celui d’un professionnel de la sécurité informatique.
Sources : Help Net Security — PHP2Shell : critical PHP vulnerabilities patched, update now! · BleepingComputer — PHP ships emergency patches for critical PHP2Shell flaws · The Repository — PHP patches critical PHP2Shell vulnerabilities as hosts race to protect customers · Sansec — PHP2Shell · Meow Apps — PHP2Shell : what it is, and what to do on your WordPress site · Clubic — Failles PHP : votre hébergeur protège-t-il vraiment votre site ?
