PHP2Shell : pourquoi votre site en PHP 7 ou 8.1 est exposé, et que faire maintenant

Le 21 octobre 2026, l’équipe de PHP a publié en urgence de quoi corriger deux failles très graves, surnommées PHP2Shell. PHP fait tourner une bonne partie des sites web, dont tous les WordPress. L’image la plus proche : on vient de découvrir que la serrure de millions de portes d’entrée s’ouvre avec un trombone. Et si votre site tourne encore en PHP 7.4, 8.0 ou 8.1, le fabricant ne vend même plus de serrure de remplacement.

La suite explique, sans jargon, ce que ça change pour votre entreprise et quoi demander à votre prestataire cette semaine.

PHP, c’est quoi, et pourquoi sa version compte

Ce que vos visiteurs voient, c’est la carrosserie : le design, les photos. PHP, c’est le moteur en dessous. Quand un client valide sa commande ou vous envoie un message par le formulaire de contact, c’est PHP qui fait le travail.

Ce moteur existe en plusieurs générations, qu’on appelle des versions (7.4, 8.1, 8.5…). Chacune est entretenue quelques années, puis le constructeur arrête de produire les pièces. Votre voiture de 2009 roule peut-être encore très bien. Mais si on découvre demain un défaut sur ses freins, le constructeur ne fournira pas de pièce corrigée. Les anciennes versions de PHP en sont là.

Ce qui s’est passé le 21 octobre

Des chercheurs ont trouvé deux défauts dans PHP, enregistrés sous les noms CVE-2026-109618 et CVE-2026-109619. Leur gravité est notée 9,2 sur 10. Un pirate peut s’en servir pour prendre la main sur votre serveur à distance, sans mot de passe. Il peut ensuite copier votre fichier clients ou rediriger vos visiteurs vers un faux site.

Les pirates n’ont donc pas attendu l’annonce pour attaquer. C’est logique : quand un cambrioleur apprend qu’un modèle de serrure est défectueux, il fait le tour du quartier avant que tout le monde ait changé la sienne.

Pourquoi PHP2Shell ne ressemble pas aux autres failles

D’habitude, une alerte de sécurité vise un élément précis du site, une extension WordPress par exemple. On la met à jour et c’est réglé, un peu comme on change une fenêtre qui ferme mal. Cette fois, le problème est dans la serrure de la porte d’entrée de l’immeuble.

L’attaque passe avant même que votre site ne démarre. Un WordPress à jour et un module de sécurité ne servent donc à rien ici : votre porte d’appartement peut être blindée, le cambrioleur est déjà dans la cage d’escalier. Des chercheurs ont d’ailleurs réussi à prendre le contrôle de sites WordPress, Drupal et Joomla de cette façon. Les bonnes pratiques de sécurité WordPress restent utiles, mais elles ne remplacent pas la mise à jour de PHP.

Le type d’hébergement n’y change rien non plus. Un petit hébergement à quelques francs par mois est aussi concerné qu’un serveur dédié.

Êtes-vous concerné ? Votre risque version par version

Toutes les versions de PHP antérieures au 21 octobre sont touchées. La vraie question est la même que chez le garagiste : existe-t-il encore une pièce de rechange pour votre modèle ?

Les versions encore plus anciennes (PHP 5, 7.0 à 7.3) sont dans une situation pire : elles accumulent des années de défauts jamais réparés.

Pour 7.4, 8.0 et 8.1, certains hébergeurs ont fabriqué eux-mêmes une réparation de fortune. C’est mieux que rien, mais c’est comme une pièce bricolée sur une voiture qui n’est plus produite : elle roule aujourd’hui, et à la prochaine panne, il n’y aura peut-être plus personne pour la réparer.

Comment vérifier la version PHP de votre site

Vous n’avez pas besoin de compétences techniques pour obtenir la réponse. Commencez par le test ci-dessous : il lit ce que votre serveur affiche publiquement.

Beaucoup de serveurs masquent leur version, et c’est plutôt bon signe. Dans ce cas, trois façons de l’obtenir, de la plus simple à la plus directe :

1. Le plus simple : écrivez à votre prestataire web ou à votre hébergeur. Une ligne suffit : « Quelle version de PHP fait tourner notre site, et le correctif du 21 octobre est-il installé ? » Un prestataire sérieux vous répond dans la journée.
2. Si vous avez un site WordPress, connectez-vous à l’administration, puis Outils, Santé du site, onglet Infos, rubrique Serveur.
3. Si vous avez accès à votre espace d’hébergement (Infomaniak, Hostpoint, cPanel, Plesk…), la version figure en général dans les réglages du domaine.

Méfiez-vous d’une réponse du type « tout est à jour, pas d’inquiétude ». Demandez le numéro de version exact, comme vous demanderiez à votre garagiste la date de la dernière révision plutôt que de vous contenter d’un « elle roule bien ». Si personne ne sait vous répondre, c’est déjà un signal d’alerte.

Que faire maintenant, selon votre version

La seule vraie protection, c’est de mettre PHP à jour. Ce qui change d’une entreprise à l’autre, c’est l’ampleur du travail.

PHP 8.3, 8.4 ou 8.5 : une simple vidange

Votre prestataire installe la version corrigée, en général sans que vos clients ne remarquent rien. Demandez-lui de le faire maintenant et de vous le confirmer par écrit.

PHP 8.2 : un contrôle technique qui expire dans deux mois

Le correctif existe, faites-le installer tout de suite. Mais cette version ne sera plus entretenue après le 31 décembre 2026. Prévoyez le passage à une version plus récente dès maintenant, parce qu’entre les fêtes et la clôture des comptes, décembre passe vite.

PHP 7.4, 8.0 ou 8.1 : il faut changer de moteur

Ici, une mise à jour ne suffit pas. Un site conçu pour PHP 7 ne fonctionne souvent pas tel quel sous PHP 8, de la même façon qu’on ne pose pas un moteur neuf sans toucher à la boîte de vitesses. Demandez des protections provisoires à votre prestataire, puis lancez un projet de migration sans attendre.

Dans tous les cas, faites vérifier que personne n’est déjà entré. Les premières tentatives d’attaque datent du 17 octobre : comme après une série de cambriolages dans le quartier, on fait le tour de la maison même si la porte semble intacte.

Les 5 questions à poser à votre prestataire cette semaine

Vous n’avez pas à connaître les détails techniques. Votre rôle est de poser les bonnes questions et d’obtenir des réponses claires. Copiez-collez cette liste dans un e-mail :

1. Quelle version exacte de PHP fait tourner notre site ?
2. Le correctif publié le 21 octobre 2026 est-il installé ?
3. Si notre version n’a plus de correctif, quelles protections provisoires avez-vous mises en place ?
4. Avez-vous vérifié qu’aucune intrusion n’a eu lieu depuis le 17 octobre ?
5. Quand pouvons-nous passer à une version de PHP encore entretenue, et pour quel budget ?

Sur la question 3, gardez en tête que les protections provisoires (pare-feu, réglages du serveur) ressemblent à des barreaux posés en urgence devant une fenêtre cassée. Elles ralentissent les intrus, mais ne remplacent pas la vitre. Votre prestataire trouvera le détail des réglages recommandés dans l’annonce officielle de PHP.

Pour les entreprises suisses : ce que dit la nLPD

Depuis le 1er septembre 2023, la nouvelle loi sur la protection des données (nLPD) oblige toute entreprise à protéger correctement les données de ses clients (art. 8). Garder un site sur une version de PHP sans correctif, alors que la faille est connue de tous, revient à laisser les dossiers clients dans un bureau dont on sait que la serrure est cassée. En cas de problème, difficile d’expliquer qu’on a fait le nécessaire.

Prenons une boutique en ligne : si son serveur est piraté, ce sont les adresses et les commandes de milliers de clients qui peuvent fuiter. Dans ce cas, l’article 24 impose d’annoncer rapidement l’incident au Préposé fédéral à la protection des données (PFPDT) si le risque pour les personnes est élevé. Au moindre doute, parlez-en à votre conseiller juridique. Pour le reste de vos obligations, notre checklist nLPD pour site web fait le tour des points techniques.

Corriger cette semaine, migrer cette année

Notre avis est assez tranché. Si votre site est en PHP 8.3 ou plus récent, c’est un mauvais moment à passer, réglé en une intervention. S’il est en 7.4, 8.0 ou 8.1, cette faille est le signal que vous repoussiez sans doute depuis longtemps : votre site doit être modernisé. Ce n’est pas agréable à entendre, mais mieux vaut planifier ce chantier maintenant que le découvrir le lendemain d’une intrusion.

Pour savoir quelle trajectoire convient à votre application (simple mise à jour, migration ou réécriture), lisez notre article Migrer une application PHP 7 vers PHP 8. Et si vous cherchez un serveur entretenu au quotidien, voyez notre offre d’hébergement et d’infogérance.

Questions fréquentes

Qu’est-ce que PHP2Shell ?

C’est le surnom donné à deux failles critiques de PHP publiées le 21 octobre 2026, CVE-2026-109618 et CVE-2026-109619. Elles permettent d’exécuter du code sur un serveur sans s’authentifier. Le projet PHP n’utilise pas ce nom.

Mon site WordPress est-il concerné ?

Oui, s’il tourne sur une version de PHP non corrigée. La faille est dans PHP, pas dans WordPress : mettre à jour WordPress ou ses plugins ne suffit pas.

Quelles versions corrigent la faille ?

PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Il n’existe aucun correctif officiel pour PHP 8.1 et les versions antérieures.

Mon hébergeur dit avoir fait la mise à jour, suis-je protégé ?

Pour ces deux failles, oui, s’il a installé la version corrigée. Demandez-lui simplement de vous confirmer par écrit le numéro de version installé et la date de l’intervention.

Sources

• Projet PHP, annonces de sécurité 2026
• BleepingComputer, Amazon says PHP2Shell exploitation began 4 days before patches
• TechRadar, AWS et Cloudflare sur les tentatives d’attaque
• Centre canadien pour la cybersécurité, alerte AL26-026