Le 21 octobre 2026, le projet PHP a publié des correctifs pour deux failles critiques, surnommées « PHP2Shell ». Elles touchent le langage sur lequel reposent WordPress, WooCommerce, PrestaShop et de nombreux sites sur mesure. Le même après-midi, les sites de toutes les préfectures, dont celle de La Réunion, ont été mis en maintenance préventive à la demande de l'ANSSI.
Le point que beaucoup de dirigeants ratent : mettre à jour WordPress ne corrige pas cette faille. Elle se trouve une couche plus bas, sur le serveur. Voici ce qu'il faut comprendre, et ce qu'il faut demander à votre hébergeur ou à votre prestataire.
Ce que l'on sait, d'après les sources officielles
Les faits ci-dessous viennent de l'avis publié sur php.net et de l'alerte CERTFR-2026-ALE-014 du CERT-FR (l'équipe de réponse aux incidents de l'ANSSI), toutes deux du 21 octobre 2026.
- Deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 en gravité (CVSS v4.0).
- Effet possible : exécution de code à distance sans authentification. Concrètement, un attaquant pourrait faire exécuter ses propres instructions par votre serveur, sans identifiant.
- Qui est exposé, selon php.net : « toutes les installations PHP qui servent des requêtes web », quel que soit le mode de fonctionnement (PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed). Le risque est jugé le plus élevé avec mod_php, pour lequel une démonstration d'attaque existe : une requête anonyme peut déclencher l'attaque avant même que le code du site ne s'exécute.
- Versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
- Versions anciennes : PHP 8.1 et antérieures ne reçoivent plus de mises à jour du projet PHP. Des correctifs minimaux ont été publiés pour 7.4, 8.0 et 8.1 à destination de ceux qui compilent PHP eux-mêmes ; certaines distributions et prestataires de support long terme proposent leurs propres correctifs.
Sur la marche à suivre, php.net est sans ambiguïté : « il n'existe pas de contournement complet, la mise à jour est le seul choix sûr ». Le CERT-FR recommande d'isoler les équipements concernés puis de migrer vers une version maintenue, et signale que les contournements temporaires proposés ne sont pas qualifiés par ses services.
Sur l'exploitation, restons précis. Au 26 octobre, ni php.net ni le CERT-FR n'indiquent que ces failles soient exploitées activement. Le CERT-FR a toutefois mis à jour son alerte le 22 octobre : il a désormais connaissance de preuves de concept (des démonstrations d'attaque) pour les deux vulnérabilités, sur des déploiements spécifiques de PHP. Help Net Security rapporte en revanche qu'un réseau de leurres d'Amazon a enregistré une tentative d'exploitation le 17 octobre, quatre jours avant la publication des correctifs. Une tentative isolée n'est pas une campagne d'attaques, mais le message est clair : il ne faut pas céder à la panique, il faut agir dans les jours qui viennent. Une faille de ce niveau, une fois les correctifs publics, est étudiée par tout le monde, y compris par ceux qui veulent s'en servir.
Pourquoi la mise à jour ne se fait pas dans WordPress
Un site WordPress fonctionne en couches, un peu comme une maison :
- Le site lui-même (WordPress, thème, extensions) : ce que vous mettez à jour depuis votre tableau de bord.
- Le langage PHP : le moteur qui exécute WordPress. Il est installé sur le serveur.
- Le serveur et son système : la machine, gérée par votre hébergeur ou par votre prestataire.
PHP2Shell touche la deuxième couche. Le bouton « Mettre à jour » de WordPress n'y a pas accès. Fin septembre, nous parlions d'une faille du cœur de WordPress, corrigée par une mise à jour automatique de WordPress : cette fois, c'est différent. Selon votre formule d'hébergement, la correction dépend :
| Votre situation | Qui applique le correctif | Ce que vous faites |
|---|---|---|
| Hébergement mutualisé (un espace chez un hébergeur grand public) | L'hébergeur, pour les versions de PHP qu'il maintient | Vérifier quelle version de PHP votre site utilise, et la changer dans le panneau d'administration si elle est ancienne |
| Hébergement géré par une agence ou un prestataire | Le prestataire | Lui demander par écrit si le correctif est appliqué et quand |
| Serveur dédié ou virtuel (VPS) administré en interne | Vous, ou la personne qui administre le serveur | Mettre à jour les paquets PHP du système et redémarrer les processus PHP |
| Site construit sans PHP (site statique, framework JavaScript) | Non concerné par cette faille | Vérifier quand même les autres briques (formulaires, outils tiers) |
Comment connaître votre version de PHP
Deux méthodes, sans compétence technique particulière :
- Dans WordPress : menu Outils, puis Santé du site, onglet Informations, rubrique Serveur. La ligne « Version de PHP » donne le numéro exact.
- Dans le panneau de votre hébergeur : la plupart affichent la version de PHP par site, et permettent d'en changer.
Comparez ensuite avec les versions corrigées. Exemple : si votre site tourne en 8.3, il doit être en 8.3.36 ou plus. Attention, le panneau affiche souvent seulement « 8.3 » sans le dernier chiffre : dans ce cas, seul l'hébergeur peut confirmer que le correctif est en place.
