Faille PHP « php2shell » : ce qui s’est passé et ce que nous avons fait pour les sites WordPress

Le 21 octobre 2026, deux failles critiques ont été rendues publiques dans PHP, le langage sur lequel fonctionnent la plupart des sites WordPress. Elles portent les références CVE-2026-109618 et CVE-2026-109619 et le surnom « php2shell ». Voici, sans jargon, ce que cela veut dire, ce que nous avons fait et ce que vous pouvez vérifier vous-même.

L’essentiel en trois points

• Une faille grave. Elle permet à un attaquant d’exécuter des commandes sur le serveur qui héberge un site, sans y avoir été invité. Elle est notée 9,2 sur 10 (très critique). Des attaques ont été signalées dès le 17 octobre, avant même la publication, et des robots automatiques cherchent les sites concernés.
• Un correctif existe, mais seulement pour les versions récentes. Il est inclus dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Pour PHP 8.1 et les versions plus anciennes, il n’existe aucun correctif officiel : un site qui tourne dessus reste exposé, même s’il fonctionne normalement. Les autorités vaudoises ont relayé l’alerte.
• Mettre WordPress à jour ne suffit pas. C’est la version de PHP, installée sur le serveur par l’hébergeur, qui compte. Les deux sont à surveiller.

PHP, c’est quoi ? Un peu d’histoire

PHP est un langage de programmation : un ensemble de règles permettant d’écrire les instructions qu’un ordinateur doit suivre. Sur votre site, PHP tourne sur le serveur qui l’héberge. À chaque visite, il lit ces instructions, prépare la page et la renvoie au visiteur. Pour la suite de l’article, retenez cette image : le serveur, c’est un hôtel, et PHP en est le réceptionniste.

PHP est un vieux langage. Il est né en 1994, quand l’informaticien Rasmus Lerdorf a écrit de petits outils pour savoir qui consultait son CV en ligne. Il les a appelés « Personal Home Page », d’où le nom PHP. Depuis, une grande communauté de développeurs le fait évoluer, et il s’appelle aujourd’hui « PHP: Hypertext Preprocessor ». Vous pouvez lire son histoire sur php.net ou sur Wikipédia.

Pourquoi en parle-t-on pour votre site ? Parce que WordPress, apparu en 2003, est écrit en PHP : si votre site est fait avec WordPress, il dépend de PHP. WordPress fait tourner près de 4 sites web sur 10 dans le monde, et PHP est utilisé par environ 7 sites sur 10 parmi ceux dont on connaît le langage (chiffres W3Techs du 27 octobre 2026).

Pourquoi l’âge d’une version compte-t-il ? Parce qu’une version de PHP n’est entretenue que pendant un temps limité : deux ans de mises à jour complètes (bogues et sécurité), puis deux ans de correctifs de sécurité seulement. Après quatre ans, la version arrive en « fin de vie » : elle continue de fonctionner, mais l’équipe de PHP ne la corrige plus, même pour une faille grave. C’est le cas de PHP 8.1, sortie en novembre 2021 : sa fin de vie date de fin 2025, et c’est pour cela qu’elle ne reçoit pas le correctif de la faille php2shell. Vous pouvez consulter la liste des versions encore entretenues.

Dans notre image, la version de PHP correspond à la formation du réceptionniste. Tant que la version est entretenue, il est formé à reconnaître les nouveaux pièges. Une fois qu’elle est en fin de vie, plus personne ne le forme. Pourtant, environ un site PHP sur trois tourne encore sur une version antérieure à PHP 8 : dans notre image, un hôtel dont le réceptionniste n’a pas été formé depuis des années.

La faille, expliquée avec un hôtel

Imaginez un hôtel. À l’entrée, un réceptionniste reçoit toutes les demandes des visiteurs : « Pouvez-vous me remettre ce document ? », « Quelle est l’adresse de l’hôtel ? » Il fait ce que la procédure prévoit, puis remet la réponse.

Dans votre site, ce réceptionniste s’appelle PHP. Il reçoit chaque visite, prépare la page et la renvoie. L’hôtel, c’est le serveur. Le coffre, ce sont vos données et vos accès.

Le problème de cette faille : un inconnu peut glisser au réceptionniste un message rédigé d’une façon bien précise, qu’il ne reconnaît pas comme piégé. Au lieu de le refuser, il l’exécute : il obéit à l’inconnu. Celui-ci peut alors lui faire ouvrir le coffre, récupérer les clés, installer ce qu’il veut dans l’hôtel, sans jamais avoir été invité.

Le correctif ne transforme pas l’hôtel : il apprend au réceptionniste à reconnaître ce piège et à le refuser.

Pourquoi mettre WordPress à jour ne suffit pas

Un site est fait de plusieurs couches empilées : votre contenu, WordPress et ses extensions, PHP, puis le serveur. WordPress, c’est le décor des chambres : on peut le tenir impeccable, le réceptionniste reste celui qui reçoit les demandes de l’extérieur. Les deux sont à surveiller.

Quelles versions de PHP sont corrigées ?

Le correctif existe seulement pour les versions récentes. Pour la version 8.1 et les versions plus anciennes, il n’y en a pas. Et le détail compte : une version 8.3.35 n’est pas corrigée, une version 8.3.36 l’est.

Pourquoi c’est sérieux pour une PME

Un site n’est pas une simple vitrine : c’est un programme installé sur un serveur. Si un attaquant en prend le contrôle, il peut s’en servir pour envoyer des courriels indésirables en votre nom, afficher de la publicité frauduleuse, voler des données (contacts, commandes) ou rendre le site indisponible pendant des jours. Pour une boutique ou un site de réservation, c’est du chiffre d’affaires perdu et de la confiance abîmée.

Ce que nous avons fait

Dès que la faille a été connue, nous avons agi par ordre de risque :

1. Un inventaire complet de tous les sites que nous hébergeons ou suivons, répartis chez quatre hébergeurs différents.
2. La version de PHP corrigée sur chaque site hébergé chez nous, avec un contrôle des pages avant et après l’opération et un retour en arrière prévu (et une sauvegarde avant toute intervention plus profonde). Les sites inutilisés ont été suspendus par précaution.
3. La vérification chez les hébergeurs tiers que le correctif était bien en place. Attention : chez certains, le numéro de version ne change pas quand le correctif est posé. Nous avons donc lu les journaux des paquets et les dates de fabrication, au lieu de nous fier au seul numéro.
4. Pour les clients sous contrat de maintenance, bien plus que PHP : mise à jour de WordPress et de ses extensions, essais et contrôle de chaque page importante. Ce qui touche aux paiements et aux réservations n’est modifié qu’avec un test, parce qu’une mise à jour qui casse une caisse en ligne coûte plus cher que la faille.
5. L’information des clients : nous écrivons à chacun pour lui dire où en est son site.

Votre site est-il protégé ? Trois situations

1. Vous avez un contrat de maintenance avec nous. Nous nous en sommes occupés. Vous n’avez rien à faire et vous recevez un message qui détaille ce qui a été fait pour votre site.

2. Votre site est hébergé chez nous, sans contrat de maintenance. Nous avons corrigé la version de PHP, car c’était le minimum vital. En revanche, nous ne suivons pas WordPress ni ses extensions : leurs mises à jour, la sauvegarde complète quotidienne et la surveillance de la sécurité ne sont pas assurées. Un site qui n’est pas suivi reste exposé aux autres failles, et les conséquences d’un piratage relèvent aussi de sa responsabilité.

3. Votre site est hébergé ailleurs, sans contrat. Nous ne pouvons pas agir à votre place. Voici ce qu’il faut faire aujourd’hui.

Les cinq vérifications à faire vous-même

1. Demandez à votre hébergeur quelle version de PHP fait tourner votre site et si le correctif de la faille y est appliqué. Une version 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 (ou plus récente) est corrigée. Une version 8.1, 8.0, 7.x ou plus ancienne ne l’est pas et ne le sera sans doute jamais.
2. Regardez la version de WordPress. Dans l’administration, « Tableau de bord » puis « Mises à jour ». Un WordPress très ancien (4.x ou 5.x) tourne presque toujours sur un PHP lui aussi ancien : c’est un signal d’alerte.
3. Vérifiez que vous avez une sauvegarde récente, complète et testée (fichiers et base de données), stockée ailleurs que sur le serveur du site.
4. Faites le ménage des comptes : supprimez les administrateurs que vous ne connaissez pas, changez les mots de passe faibles, retirez les extensions que vous n’utilisez plus.
5. Demandez qui est responsable du suivi de votre site. S’il n’y a pas de réponse claire, personne ne l’est.

Ce que nous retenons

• Entretenir coûte moins cher que réparer. Une mise à jour planifiée et testée coûte quelques heures ; un site piraté coûte des jours, et parfois des clients.
• Une sauvegarde qui n’a jamais été restaurée n’est qu’une hypothèse.
• Les mises à jour automatiques ne sont pas une stratégie. Elles se font sans test, et une mise à jour peut elle-même casser un site. On sauvegarde avant, on contrôle après.
• Le jour où la faille tombe, il est trop tard pour décider qui s’occupe du site.

Un contrat de maintenance, ça couvre quoi ?

Les mises à jour de PHP, de WordPress et de ses extensions, des sauvegardes complètes régulières, la surveillance de la sécurité et de la disponibilité, et quelqu’un qui répond quand une urgence comme celle-ci arrive. Pour un site que vous ne voulez pas surveiller vous-même, c’est la façon la plus simple de ne pas y penser.

Vous voulez savoir où en est votre site ou le confier à quelqu’un qui le suit ? Écrivez-nous : nous le vérifions et nous vous envoyons une proposition.

Sources : informations publiques sur les vulnérabilités CVE-2026-109618 et CVE-2026-109619, publiées le 21 octobre 2026, et alerte des autorités vaudoises.