Faille PHP2Shell : votre site WordPress est-il concerné ?

Votre site est-il concerné ?

Commencez par vérifier quelle version de PHP fait tourner votre site. Dans l’administration de WordPress, ouvrez Outils, puis Santé du site, onglet « Informations », et dépliez la section « Serveur ». La ligne « Version de PHP » donne la version.

Sans vous connecter à votre site, notre analyse gratuite indique aussi sa version de PHP quand le serveur la communique, ce que certains hébergeurs évitent. Elle signale une version qui ne reçoit plus de correctifs de sécurité.

La ligne « PHP SAPI » indique comment PHP tourne sur le serveur : apache2handler correspond au mode « mod_php », le plus exposé à cette attaque, fpm-fcgi à PHP-FPM et litespeed à LiteSpeed. Si vous voyez apache2handler avec une version non corrigée, contactez votre hébergeur sans attendre.

Sur un hébergement mutualisé, la mise à jour de PHP est à la charge de l’hébergeur. OVHcloud a corrigé toutes ses versions de PHP 7.4 à 8.5 le 21 octobre, puis celles de 5.3 à 7.3 le 23 octobre (son suivi de l’incident, en anglais). o2switch a corrigé les versions 5.2 à 8.5 et rappelle qu’un numéro inchangé ne signifie pas que le correctif manque (son article).

Un bon indice est la date de compilation de PHP (« Build Date »), au 21 octobre 2026 ou après. Elle figure dans la page « PHP Info » de l’espace client de certains hébergeurs. Si vous créez vous-même une page phpinfo pour la lire, supprimez-la aussitôt après : elle dévoile la configuration du serveur.

Si votre site est géré par une agence ou un prestataire, demandez-lui par écrit quelle version de PHP fait tourner le site et si le correctif des deux failles y est appliqué.

Si vous louez un serveur que vous administrez vous-même, installez la version corrigée de PHP, puis redémarrez PHP-FPM ou Apache : sans redémarrage, l’ancienne version reste en mémoire et continue de répondre. Si aucune version corrigée n’existe pour votre système, WordPress.org et les autorités américaine et britannique de cybersécurité conseillent de mettre le serveur hors ligne en attendant. Les réglages de contournement proposés par PHP réduisent le risque sans le supprimer.

Des failles sérieuses, mais pas une raison de paniquer

Les deux failles se trouvent dans la façon dont PHP traite les demandes qui arrivent au site, en particulier les envois de fichiers. Le problème survient quand une demande échoue en cours de route, par manque de mémoire ou sur une erreur : PHP peut alors rester dans un état incohérent, que l’attaquant détourne pour lui faire exécuter son propre code. Les versions touchées remontent jusqu’à PHP 5.4, sortie en 2012.

Trois points expliquent l’inquiétude des spécialistes :

• l’attaque ne demande ni compte ni mot de passe ;
• elle peut aboutir avant même que WordPress ne démarre : aucune extension installée dans WordPress ne peut donc l’arrêter à elle seule ;
• l’un des mécanismes visés, le suivi de progression des envois de fichiers, est actif par défaut dans PHP. WordPress ne s’en sert pas, mais cela ne le protège pas.

Dans leur laboratoire, sur un serveur Apache en mode « mod_php », les chercheurs ont ainsi pris le contrôle d’un WordPress sans aucune extension.

Mais le risque réel dépend de la façon dont PHP tourne sur le serveur. L’attaque complète a été démontrée en mode « mod_php », quand PHP fonctionne à l’intérieur du serveur web Apache. Avec PHP-FPM ou LiteSpeed, deux autres façons de faire tourner PHP, répandues chez les hébergeurs, l’attaque doit passer par le code du site, et WordPress en contient qui pourrait servir. Aucune attaque qui marche sur n’importe quel site n’a été démontrée publiquement à ce jour : le risque y est moindre, mais pas nul.

À ce jour, aucun site WordPress piraté par ce moyen n’a été documenté publiquement. La première attaque réussie, confirmée publiquement le 26 octobre, visait un serveur piège, volontairement configuré pour être facile à attaquer.

PHP 8.1 et plus ancien : le vrai problème

D’après les statistiques de WordPress, un site WordPress sur trois tourne encore en PHP 8.1 ou plus ancien : 33,6 % le 27 octobre 2026. Ces versions ne reçoivent plus de mises à jour du projet PHP, la 8.1 depuis le 31 décembre 2025, la 7.4 depuis novembre 2022. Vu la gravité de PHP2Shell, l’équipe de PHP a fait une exception : elle a publié un correctif pour les versions 7.4, 8.0 et 8.1. Les hébergeurs et les distributions Linux devaient l’intégrer eux-mêmes, et la plupart l’ont fait. Rien ne garantit qu’ils le referont pour la prochaine faille.

Visez PHP 8.3 ou 8.4 (WordPress recommande 8.3 ou plus récent). La version 8.2 est corrigée, mais elle ne recevra plus de correctifs après le 31 décembre 2026. Pour changer de version sans casser votre site, suivez la méthode décrite dans notre article sur WordPress 7, à la partie consacrée à PHP.

Une semaine sous tension

Les failles ont été trouvées cet été par des chercheurs en sécurité, aidés en partie par des outils d’intelligence artificielle. La société Calif a donné l’alerte au projet PHP le 11 août, suivie de Wiz Research le 24 août. La PHP Foundation, qui finance une partie des développeurs de PHP, reconnaît que l’une des deux failles avait été entrevue dès 2024, lors d’un audit. Elle attribue la lenteur de la correction à « un échec structurel » : le processus de décision de l’équipe de sécurité de PHP et le manque de moyens (son récit, en anglais).

Le mardi 20 octobre, vers 17 h (heure de Paris), les identifiants officiels des deux failles, CVE-2026-109618 et CVE-2026-109619 (qu’est-ce qu’une CVE ?), ont commencé à circuler sur des forums et des réseaux sociaux, avec une note de gravité fausse : 10 sur 10, au lieu de 9,2. Dans la soirée, le projet PHP a avancé d’un jour la publication des correctifs, au lendemain. Peu après, Calif a publié par erreur une vidéo montrant son attaque en action.

Les correctifs sont sortis le mercredi 21 octobre, vers 16 h : PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12 (annonce officielle, en anglais). Les tentatives d’attaque, elles, avaient déjà commencé : Amazon en a observé une dès le 17 octobre, quatre jours avant les correctifs. Le 26 octobre, l’agence américaine de cybersécurité (CISA) a inscrit les deux failles sur sa liste des vulnérabilités exploitées, sans détailler les cas. Le même jour, le CERT-FR, le centre d’alerte de l’ANSSI, a fait état de tentatives d’exploitation visant des configurations particulières de PHP.

Le 23 octobre, PHP a signalé une troisième faille voisine. Elle suppose un réglage rare, que l’application doit elle-même modifier en cours de route. Le projet juge son exploitation peu probable et la corrigera dans sa prochaine version ordinaire.

Ce que cette faille rappelle

PHP2Shell ne sera pas la dernière faille de ce genre. Ces derniers jours, deux choses ont compté : un hébergeur qui corrige vite, et une version de PHP encore maintenue, qui reçoit ses correctifs sans dépendre de la bonne volonté de l’hébergeur. Le premier se choisit au moment de prendre un hébergement. La seconde se vérifie au moins une fois par an : les versions récentes de PHP arrivent en fin de vie un 31 décembre.

Questions fréquentes

Dois-je mettre à jour WordPress à cause de PHP2Shell ?

Non. WordPress.org l’a précisé dès le 21 octobre : aucune mise à jour de WordPress n’est nécessaire ni prévue pour ces failles (son annonce, en anglais). Continuez simplement à tenir WordPress à jour comme d’habitude.

Une extension de sécurité me protège-t-elle ?

Pas à elle seule. L’attaque peut aboutir avant que WordPress ne démarre, donc avant toute extension. Seul un filtre placé devant PHP, chez l’hébergeur ou chez un service comme Cloudflare, peut arrêter les variantes connues de l’attaque, et il ne remplace pas la mise à jour de PHP.

Mon site affiche une version plus ancienne que les versions corrigées : est-il vulnérable ?

Pas forcément. Sur un hébergement mutualisé, regardez la date de compilation de PHP ou posez la question à votre hébergeur, comme expliqué plus haut. Sur un serveur que vous gérez vous-même, consultez le journal des mises à jour du paquet PHP de votre système : sous Ubuntu 24.04, par exemple, la version corrigée s’affiche toujours « 8.3.6 ».

Mon site a-t-il pu être piraté par cette faille ?

C’est peu probable, mais pas exclu si votre PHP n’a pas été corrigé à temps. À ce jour, aucun site WordPress piraté par ce moyen n’a été documenté publiquement. Parmi les tentatives observées, certaines cherchaient à lire le fichier wp-config.php, où se trouvent les accès à la base de données. D’autres voulaient déposer un fichier PHP dans le dossier des fichiers envoyés (wp-content/uploads), dans celui des extensions ou dans celui du thème. Par précaution, cherchez-y un fichier .php que vous ne connaissez pas, avec le gestionnaire de fichiers de votre hébergeur. Notre article pour savoir si votre site est piraté détaille les autres signes.