Faille PHP2Shell : ce que vous devez vérifier sur votre site WordPress

Votre site WordPress fonctionne grâce à PHP, le langage qui tourne sur le serveur et fabrique chaque page affichée à vos visiteurs. Deux failles critiques ont été découvertes dans PHP lui-même et corrigées en urgence le 21 octobre 2026. Elles permettent à un inconnu, sans identifiant ni mot de passe, de faire exécuter ses propres commandes sur le serveur qui héberge votre site. Les premières tentatives d’attaque ont déjà été repérées.

La correction ne vous demande presque jamais d’intervenir vous-même. Elle demande en revanche de vérifier que votre hébergeur l’a vraiment appliquée.

Que s’est-il passé ?

Les deux failles portent les références CVE-2026-109618 et CVE-2026-109619. Les spécialistes les ont surnommées PHP2Shell. Leur gravité est notée 9,2 sur 10, et elles touchent toutes les versions de PHP depuis la 5.4, quelle que soit l’application installée par-dessus : WordPress, mais aussi Drupal, Laravel ou un site développé sur mesure. Votre WordPress, vos extensions et votre thème n’y sont pour rien.

Le calendrier s’est emballé. Les détails techniques ont circulé sur internet le 20 octobre, avant la sortie du correctif, et l’équipe de PHP a dû avancer sa publication au 21 octobre à 16 h (heure de Paris). Plusieurs sociétés de sécurité ont relevé des tentatives d’exploitation le jour même (SecurityWeek). Amazon en a même détecté une le 17 octobre, quatre jours avant que les failles soient rendues publiques (Help Net Security). Le CERT-FR, le centre d’alerte de l’État en cybersécurité, a publié une alerte le 21 octobre (alerte CERTFR-2026-ALE-014).

Aucun chiffre public ne mesure encore le nombre de sites WordPress touchés. Ce n’est pas une raison pour attendre.

Quelles versions de PHP sont corrigées ?

Votre site est protégé s’il tourne sur l’une de ces versions, ou sur une version plus récente de la même branche :

• PHP 8.5.12 ;
• PHP 8.4.27 ;
• PHP 8.3.36 ;
• PHP 8.2.35.

PHP 8.1 et toutes les versions antérieures ne reçoivent plus de correctif officiel, car elles ne sont plus maintenues. Certains hébergeurs les ont tout de même corrigées par leurs propres moyens, c’est le cas d’o2switch (voir plus bas). C’est un filet de sécurité, pas une raison de rester : rien ne garantit que la prochaine faille sera, elle aussi, rattrapée. Si votre site en est encore là, le passage à une version récente cesse d’être un chantier à prévoir « un jour ». C’est la priorité, avec une sauvegarde complète avant la bascule.

Pour connaître votre version, ouvrez votre tableau de bord WordPress, menu Outils, puis Santé du site. Dans l’onglet Informations, la rubrique Serveur indique la version de PHP utilisée.

Qui doit installer le correctif ?

Dans la grande majorité des cas, votre hébergeur. Sur un hébergement mutualisé, c’est-à-dire un serveur partagé entre plusieurs clients et entièrement géré par l’hébergeur (l’offre la plus courante pour un site vitrine), vous n’avez pas la main sur PHP.

Les hébergeurs ont d’abord posé des protections d’attente. o2switch a désactivé dès le matin du 21 octobre la fonction de PHP utilisée par les attaques connues, en attendant des versions corrigées adaptées à son infrastructure, qu’il a installées dans la nuit suivante. OVHcloud a déployé des règles de filtrage sur ses serveurs, et Cloudflare protège ses clients, offre gratuite comprise (Clubic). Ces mesures freinent les attaques sans remplacer la mise à jour : selon le CERT-FR, le contournement recommandé ne couvre qu’une des deux failles.

Vous louez un serveur privé (VPS) ou dédié ? La mise à jour vous revient, ou revient au prestataire qui l’administre : installation des versions corrigées, puis redémarrage de PHP.

Comment savoir si votre site est vraiment protégé ?

Le numéro de version ne suffit pas toujours. Un hébergeur peut intégrer le correctif dans sa propre version de PHP sans changer le numéro affiché, et la version utilisée par votre site peut différer de celle que donne le serveur en ligne de commande (Clubic). La confirmation fiable vient de l’hébergeur.

Un exemple concret : chez o2switch, PHP 8.5 est aujourd’hui en version 8.5.11-5. Ce numéro est inférieur à la version officielle corrigée (8.5.12), et pourtant le correctif est bien installé. L’explication : o2switch utilise CloudLinux, un système qui recompile PHP avec sa propre numérotation. Le repère qui ne trompe pas est la date de compilation de PHP, affichée par la fonction technique phpinfo : elle doit être du 21 octobre 2026 ou postérieure. Votre hébergeur ou votre prestataire peut la vérifier pour vous.

Posez-lui une question simple, par écrit : « Les versions de PHP corrigées contre les failles CVE-2026-109618 et CVE-2026-109619 sont-elles installées et actives sur l’hébergement de mon site ? » Une réponse du type « nous avons mis en place une protection » ne répond pas à la question. Demandez la date d’installation du correctif.

Surveillez aussi quelques signes inhabituels : un compte administrateur que vous ne connaissez pas, des fichiers apparus récemment sur l’hébergement, des tâches programmées que personne n’a créées. Ce sont les traces que conseillent de rechercher les chercheurs de watchTowr (analyse watchTowr, en anglais). Si vous en trouvez, ne supprimez rien vous-même : les journaux du serveur servent à comprendre ce qui s’est passé.

Et pour les sites dont nous assurons la maintenance ?

Tous les sites que nous maintenons sont hébergés chez o2switch. Nous l’avons contacté dès la publication des failles. Sa réponse est claire : les correctifs ont été installés dans la nuit qui a suivi leur publication, sur toutes les versions de PHP qu’il propose, y compris les plus anciennes.

Si votre site est couvert par notre contrat de maintenance de site WordPress, vous n’avez rien à faire : le suivi de cette faille fait partie de notre travail.

Que retenir pour la suite ?

Fin septembre, une faille du cœur de WordPress avait été exploitée moins de 24 heures après son correctif (notre veille du 21 au 27 septembre). Cette fois, les attaques ont commencé avant même le correctif. Le délai pour réagir se compte désormais en heures.

Une faille dans le moteur qui fait tourner votre site ne se règle ni avec une extension ni avec un clic dans WordPress. Elle se règle avec un hébergeur réactif et quelqu’un qui contrôle que le travail est fait. Vous ne savez pas qui tient ce rôle pour votre site ? Demandez un audit gratuit : nous vérifions votre version de PHP et l’état de votre hébergement.