Faille PHP php2shell : comment est-ce arrivé et comment protéger votre site ⚠️

D’habitude, une faille WordPress se loge dans une extension ou dans un thème. Cette fois, c’est le moteur qui fait tourner WordPress, PHP, qui est en cause. C’est comme une fissure dans les fondations d’un immeuble : tout le bâtiment est concerné.

Qu’est-ce que la faille php2shell ?

Php2shell est le surnom donné à deux failles du cœur de PHP qui permettent d’exécuter du code à distance sur un serveur, sans compte ni mot de passe. PHP est le langage dans lequel WordPress est écrit : chaque page de votre site passe par lui.

Les deux failles sont décrites dans l’avis de sécurité officiel de PHP :

• CVE-2026-109618 : quand la mémoire allouée à PHP vient à manquer au mauvais moment, des données à moitié préparées sont ensuite traitées comme si elles étaient valides, ce qui ouvre la voie à l’exécution de code (avis détaillé) ;
• CVE-2026-109619 : des informations liées à une requête survivent alors que la mémoire qui les contenait a été libérée, et une requête suivante peut s’en servir (avis détaillé).

Les deux sont notées 9,2 sur 10 sur l’échelle CVSS, la grille standard qui mesure la gravité d’une faille. Elles permettent aussi de lire une partie de la mémoire du serveur, mots de passe et clés d’API compris. C’est exactement le genre de mise à jour que notre service de maintenance WordPress surveille et applique pour vous.

Comment cette faille est-elle arrivée ?

La faille vient d’un mécanisme très ancien du moteur de PHP, présent depuis plus de dix ans, que personne n’avait identifié comme dangereux. Selon l’analyse de Sansec, les chercheurs de Calif ont trouvé les premières pistes d’exécution de code le 1er août 2026 et les ont signalées à PHP le 11 août, suivis par l’équipe de Wiz Research le 24 août. Ces équipes disent s’être aidées de l’intelligence artificielle.

La suite devait suivre la règle de la divulgation coordonnée : PHP prépare le correctif en secret, prévient distributions Linux et hébergeurs, puis tout le monde publie le même jour. La publication était prévue le jeudi 22 octobre. Mais le 20 octobre au matin, un message anonyme a révélé l’existence des failles sur un forum très suivi des développeurs, et les numéros CVE ont circulé sur les réseaux sociaux. PHP a donc avancé la sortie des correctifs au 21 octobre à 14 h UTC (16 h à Paris).

Entre-temps, les attaquants n’ont pas attendu. D’après la FAQ de Tenable, Amazon a repéré une première tentative d’exploitation dès le 17 octobre, avant même la fuite publique, et d’autres le 21 octobre. Cloudflare a aussi signalé des attaques le 21 au matin, avant le correctif.

Votre site WordPress est-il concerné ?

Oui, potentiellement, car la faille ne dépend ni de vos extensions ni de votre thème : c’est la version de PHP utilisée par votre hébergeur qui compte. L’équipe de PHP précise que toute installation qui répond à des requêtes web est à risque, avec un danger maximal pour les serveurs Apache équipés de mod_php, où l’attaque peut se déclencher avant même que WordPress ne s’exécute. Le mode maintenance de WordPress ne protège donc pas votre site.

Les chercheurs de Wiz ont d’ailleurs démontré une prise de contrôle sans authentification sur WordPress, Drupal et Joomla, selon le récapitulatif de Huntress. Les versions corrigées sont les suivantes :

• PHP 8.5 : version 8.5.12 ;
• PHP 8.4 : version 8.4.27 ;
• PHP 8.3 : version 8.3.36 ;
• PHP 8.2 : version 8.2.35 (cette branche arrive en fin de vie le 31 décembre 2026) ;
• PHP 8.1 et plus ancien : aucune mise à jour officielle, seulement des correctifs à compiler soi-même pour les versions 7.4, 8.0 et 8.1.

Pour connaître votre version, ouvrez Outils puis Santé du site dans votre administration, onglet Infos, rubrique Serveur. Attention, certains hébergeurs appliquent le correctif sans changer le numéro de version : en cas de doute, la réponse doit venir d’eux.

Comment protéger votre site de la faille php2shell ?

La seule protection complète est de faire tourner votre site sur une version de PHP corrigée, et l’équipe de PHP le dit sans détour : aucune autre mesure ne rend une installation sûre. Dans l’ordre :

1. Interroger votre hébergeur

Sur un hébergement mutualisé, PHP est mis à jour par l’hébergeur. Demandez par écrit si le correctif du 21 octobre est appliqué sur votre serveur.

2. Passer sur une branche de PHP encore suivie

Si votre site tourne encore en PHP 7.4, 8.0 ou 8.1, le moment est venu de monter de version depuis le panneau de votre hébergeur. Faites-le après une sauvegarde complète, puis vérifiez le site page par page. Quand il faut remplacer des extensions incompatibles, ce passage demande en général 2 à 4 heures, soit 140 à 280 € TTC au tarif normal.

3. Sur un serveur dédié ou un VPS, mettre à jour et redémarrer

Installez les paquets corrigés de votre distribution, redémarrez tous les processus PHP, puis contrôlez la version réellement utilisée par le site web, qui n’est pas toujours celle de la ligne de commande. Les réglages temporaires proposés par PHP ne sont qu’un pis-aller.

4. Surveiller les signes d’intrusion

Les tentatives ayant commencé le 17 octobre, vérifiez l’absence de nouveaux comptes administrateurs, de fichiers PHP inconnus et de tâches programmées suspectes. Si vous en trouvez, arrêtez-vous là et faites appel à un professionnel : un serveur compromis ne se nettoie pas à moitié.