Faille PHP : ni passivité ni panique

Hackeur devant son ordinateur

Le 21 octobre 2026, une faille PHP critique a touché le langage qui fait tourner presque tous les sites WordPress. Mes deux sites étaient concernés. Voici comment je l’ai traitée en quelques heures, sans paniquer et sans attendre que l’orage passe tout seul.

Ce n’est pas un tutoriel d’expert. C’est le récit d’une utilisatrice attentive, avec les étapes que n’importe qui peut suivre.

Ce qui s’est passé

Deux failles, baptisées « PHP2Shell », permettaient à un inconnu de prendre la main sur un serveur web avec une simple requête, sans mot de passe. Leur gravité est notée 9,2 sur 10.

Le projet PHP a publié les correctifs le 21 octobre. Problème : les détails avaient fuité la veille, et les premières attaques ont été repérées le matin même, avant que le correctif n’existe.

Les versions sûres sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Tout ce qui est en dessous est vulnérable. Les versions 8.1 et plus anciennes ne reçoivent plus de correctif officiel.

La couche invisible

C’est le point le plus contre-intuitif : un site WordPress parfaitement à jour restait vulnérable. La faille n’était ni dans WordPress, ni dans les extensions, ni dans le thème. Elle était en dessous, dans le moteur qui les fait tourner.

Aucun bouton « Mettre à jour » n’apparaît donc dans le tableau de bord. WordPress.org a d’ailleurs confirmé qu’aucune mise à jour de sa part n’était nécessaire.

Qui doit agir dépend de l’hébergement :

  • Hébergement mutualisé : c’est l’hébergeur qui installe le PHP corrigé. Votre rôle est de vérifier.
  • Hébergement WordPress géré : même chose, l’hébergeur s’en occupe. Demandez une confirmation.
  • Serveur que vous administrez vous-même : personne ne le fera à votre place.

Mon parcours, étape par étape

  1. Vérifier la version de PHP. Dans WordPress : Outils > Santé du site > onglet Info > section Serveur. J’étais en 8.2.34, juste en dessous de la version corrigée.
  2. Sauvegarder avant de toucher à quoi que ce soit. Les fichiers du site et la base de données, rangés chez moi, sur mon propre stockage. Mon hébergeur Infomaniak garde sept jours de sauvegardes automatiques ; je voulais une copie qui ne dépende pas de lui.
  3. Lire avant de cliquer. Mon hébergeur proposait une migration vers une nouvelle infrastructure pour accéder aux versions récentes de PHP. J’ai d’abord cherché ce que cette migration impliquait.
  4. Migrer, puis changer de version. Une fois la migration faite, j’ai passé mes deux sites en PHP 8.5.
  5. Vérifier le numéro exact. Choisir une branche ne suffit pas : il faut lire 8.5.12 ou plus. C’était le cas.
  6. Tester le site. Pages, articles, formulaires, éditeur. Tout fonctionnait.
  7. Chercher des traces d’intrusion. Aucun nouvel utilisateur administrateur, aucune extension inconnue. Une mise à jour ne répare pas un site déjà infiltré, d’où ce contrôle.

Rien de spectaculaire. Juste un ordre logique, et un peu de temps devant soi.

Ce que j’en retiens

Ni passive, ni paniquée. La passivité aurait été de me dire que l’hébergeur s’en occuperait. La panique, de cliquer sur tout ce qui portait le mot « sécurité », ou de payer l’une des interventions d’urgence vendues au prix fort dans les heures qui ont suivi. Entre les deux, il y a la vérification calme.

On ne maîtrise pas toute la chaîne, mais on peut l’interroger. Mon site repose sur des couches que je ne vois pas : le langage, le serveur, l’hébergeur. La souveraineté numérique, ce n’est pas tout contrôler. C’est savoir qui fait quoi, et pouvoir poser la bonne question à la bonne personne.

La sauvegarde est un geste d’autonomie. Une copie rangée chez soi, c’est la liberté de revenir en arrière sans dépendre de personne.

Le slow n’est pas la lenteur. J’ai agi en quelques heures. Mais chaque étape a été faite une fois, dans le bon ordre, au calme. Moins de friction, pas moins d’action.

Pour aller plus loin

Share the Post:

Related Posts