PHP2Shell : votre site web est peut-être une porte ouverte

01Ce qui s’est passé, en clair

Le 20 octobre 2026, l’équipe qui maintient PHP a prévenu qu’une mise à jour de sécurité urgente arrivait le lendemain. Le 21 octobre, elle a publié les correctifs pour deux failles, surnommées PHP2Shell (références officielles : CVE-2026-109618 et CVE-2026-109619).

Pour situer : au-delà de 9, on parle de « critique », la catégorie où l’on ne planifie pas, on agit.

Problème supplémentaire : des détails techniques ont fuité avant la publication du correctif. Dès les premiers jours, des acteurs comme Cloudflare ont observé des tentatives d’attaque. Autrement dit, les attaquants n’ont pas attendu.

02Où en est-on au 26 octobre : les faits

À ce jour, aucune entreprise victime n’a été nommée publiquement. Mais depuis ce week-end, on sait que l’attaque fonctionne réellement. Avant le 24 octobre, les analystes ne voyaient que des repérages et des tentatives ratées, sans compromission connue. Ce n’est plus le cas.

1. 17 oct.

   Amazon détecte une première tentative sur ses serveurs pièges, quatre jours avant la divulgation.

   Source : Amazon
2. 20 oct.

   Fuite des détails. PHP annonce un correctif pour le lendemain.

   Source : Rescana
3. 21 oct. (nuit)

   Premiers codes d’attaque publiés, une douzaine d’heures avant l’annonce officielle. Selon l’équipe PHP, aucun ne fonctionnait.

   Source : Infosecurity Magazine
4. 21 oct.

   Correctifs publiés. Dans les heures qui suivent, Amazon, watchTowr et Cloudflare observent des vagues de tentatives. Amazon parle d’exploitation « large » : de nombreuses tentatives, sans succès confirmé à ce moment-là.

   Sources : Amazon, watchTowr
5. 22 oct.

   Des chercheurs découvrent, sur un serveur d’attaquant, un outil d’attaque testé et des scripts ayant déjà passé au crible une vingtaine de sites publics, dont en Europe.

   Source : SOCRadar
6. 23 oct.

   L’équipe PHP signale une nouvelle faille du même type (CVE-2026-115560), sans correctif pour l’instant, exploitable seulement dans des configurations inhabituelles. Une mesure provisoire est publiée.

   Source : BleepingComputer
7. 24 oct. · rendu public le 26

   Premières prises de contrôle réussies : trois serveurs pièges non corrigés (Apache, PHP 8.4.26) ont exécuté les commandes d’attaquants, avec 35 shells lancés. Relevé par le chercheur Adel Karimi (Perplexity), analyse confirmée par le chercheur Marcus Hutchins, rendu public par BleepingComputer le 26 octobre.

   Source : BleepingComputer

Le précédent à garder en tête : en juillet 2026, la faille wp2shell, qui touchait directement WordPress, avait été exploitée massivement par plusieurs groupes d’attaquants après la publication d’un code d’attaque (Mishcon de Reya). Le scénario de PHP2Shell suit le même chemin.

03Pourquoi ça vous concerne (même si vous n’êtes pas « dans l’informatique »)

PHP, vous ne le voyez jamais, mais il est partout. C’est le moteur qui tourne derrière :

• Sites WordPress (vitrines, blogs, boutiques WooCommerce)
• Drupal, Joomla, Magento
• Applications Laravel et outils métier
• Extranets et espaces clients
• Formulaires de devis « sur mesure »

Si votre entreprise a un site web, il y a de fortes chances qu’il tourne sur PHP.

Ce qu’un attaquant peut faire avec cette faille : envoyer une simple requête sur votre site, sans mot de passe ni compte, et exécuter ses propres commandes sur le serveur. Concrètement :

• VolVoler les données de vos clients (formulaires, comptes, commandes).
• PiègeInstaller une fausse page de paiement ou de connexion sur votre propre site.
• UsurpationUtiliser votre serveur pour envoyer du spam ou attaquer d’autres victimes, avec votre nom de domaine.
• SabotageDéfigurer le site ou le chiffrer pour vous réclamer une rançon.

« Mon site est trop petit pour intéresser quelqu’un » ne tient pas.

Ces attaques sont automatisées. Des robots balaient Internet à la recherche de serveurs non corrigés. Ils ne choisissent pas leur cible, ils prennent ce qui est ouvert.

04Ce que vous devez faire cette semaine

1. Identifiez qui gère votre site. Une agence, un freelance, un hébergeur (OVH, o2switch, Ionos…), un salarié en interne ? C’est à cette personne que vous posez les questions suivantes.

2. Posez-lui ces trois questions, par écrit :

   • « Quelle version de PHP tourne sur notre site ? »
   • « Est-elle corrigée contre PHP2Shell (CVE-2026-109618 et 109619) ? »
   • « Si oui, depuis quand ? Si non, quand ? »

3. Vérifiez la réponse. Les versions corrigées sont :

   Grille de vérification · versions corrigées le 21/10/2026

   Si votre site est en…	Il doit être au minimum en…
   PHP 8.5	8.5.12
   PHP 8.4	8.4.27
   PHP 8.3	8.3.36
   PHP 8.2	8.2.35Fin de support officielle le 31 décembre 2026 : prévoyez déjà la suite.
   PHP 8.1 ou plus ancien	⚠️ Pas de nouvelle version officielle : migration à prévoirL’équipe PHP a seulement publié des correctifs minimaux à appliquer au code source (pour 7.4, 8.0 et 8.1), et certaines distributions Linux rétroportent le correctif : à confirmer par écrit avec votre prestataire.

   Pas à pas

   Comment vérifier vous-même votre version PHP

   Sur un site WordPress (compte administrateur) :

   • Outils
   • →
   • Santé du site
   • →
   • Informations
   • →
   • Serveur

   • Lisez la ligne « Version de PHP » et comparez-la au tableau ci-dessus.
   • Autres sites : la version PHP est généralement affichée (et réglable) dans l’espace client de votre hébergeur, rubrique de configuration PHP de votre hébergement.
   • Notez la version et la date du jour : c’est le début de votre « preuve écrite ».
   !

   Attention au piège du numéro de versionCertains serveurs (Debian, Ubuntu…) installent le correctif sans changer le numéro affiché. Un site peut donc indiquer « 8.3.6 » et être protégé. Si le numéro vous paraît ancien, ne paniquez pas : demandez à votre prestataire de confirmer par écrit que le correctif PHP2Shell est bien en place.

4. Si votre site tourne sur PHP 8.1 ou plus ancien, c’est le vrai signal d’alarme. Ces versions ne sont plus maintenues officiellement : votre site vivait déjà sans filet avant cette faille. Demandez un plan de migration, avec une date.

Le modèle d’e-mail à envoyer à votre prestataire

Remplacez les éléments entre crochets. Cliquez dans le cadre pour tout sélectionner, puis copiez (Ctrl+C ou ⌘+C).

Objet : [Nom du site] – correctif de sécurité PHP2Shell (CVE-2026-109618 / CVE-2026-109619)

Bonjour [Prénom],

Deux failles critiques de PHP, surnommées PHP2Shell (CVE-2026-109618 et CVE-2026-109619, gravité 9,2/10), ont été corrigées le 21 octobre 2026 dans les versions PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.

Pouvez-vous me confirmer par écrit, d’ici le [date] :

1. Quelle version de PHP tourne sur notre site [adresse du site], ainsi que sur nos autres sites ou espaces en ligne que vous gérez ?
2. Est-elle corrigée contre PHP2Shell ? Si oui, depuis quelle date ? Si non, à quelle date le sera-t-elle ?
3. Si nous sommes en PHP 8.1 ou plus ancien : quel est votre plan de migration, et à quelle date ?
4. Si le site n’était pas corrigé dès le 21 octobre : pouvez-vous vérifier qu’aucune intrusion n’a eu lieu depuis le 17 octobre (fichiers modifiés, comptes administrateurs inconnus, comportements anormaux) et m’envoyer un court compte rendu ?

Merci d’avance pour votre retour.

[Votre nom]
[Entreprise – téléphone]

05Les fausses bonnes idées

• « On a un pare-feu, on est protégés. »
  Les règles de filtrage déployées en urgence bloquent les attaques connues. L’équipe PHP elle-même le répète : seule la mise à jour corrige le problème.
• « On a un antivirus. »
  Il protège vos ordinateurs, pas le serveur qui héberge votre site.
• « Notre hébergeur s’en occupe forcément. »
  Parfois oui, parfois non. Sur un hébergement mutualisé, c’est souvent vous (ou votre prestataire) qui choisissez la version de PHP. Ne supposez pas : vérifiez.

06Et si vous découvrez que le site n’était pas à jour ?

Mettre à jour ferme la porte. Mais la porte est peut-être restée ouverte plusieurs jours. Demandez aussi à votre prestataire de vérifier qu’aucune intrusion n’a eu lieu depuis le 17 octobre (date de la première tentative connue) jusqu’au jour de la mise à jour :

• fichiers modifiés sur le serveur ;
• comptes administrateurs inconnus ;
• comportements anormaux du site.

07Les prochains mois : ce qui risque d’arriver

Le correctif existe, mais l’histoire ne s’arrête pas là. Voici les conséquences les plus probables, du plus court au plus long terme.

• Les semaines qui viennent : la vague automatisée. Une fois les détails techniques publics, les attaques passent des spécialistes aux robots. Les premières victimes seront les sites oubliés : vieux WordPress jamais mis à jour, sites de campagne, mini-sites d’événements encore en ligne.
• Les intrusions découvertes en retard. Un serveur compromis avant le correctif peut le rester après. Certaines entreprises découvriront dans plusieurs mois qu’un accès a été installé en octobre : fuite de données, pages piégées, serveur revendu à d’autres pirates.
• La fin forcée des vieilles versions. Les sites encore en PHP 8.1 ou plus ancien n’ont pas de nouvelle version officielle (seulement des correctifs minimaux à appliquer au code source, ou des rétroportages de certaines distributions). On peut s’attendre à ce que des hébergeurs durcissent le ton et poussent, voire imposent, la montée de version. Pour certains sites, ça voudra dire une refonte non prévue au budget.
• Les assureurs et les clients vont poser des questions. Une faille de cette ampleur alimente les questionnaires des assureurs cyber et des grands donneurs d’ordre : « Comment gérez-vous les mises à jour critiques ? En combien de temps ? » Mieux vaut avoir une réponse écrite.
• Pour les entreprises concernées par NIS2, la gestion des vulnérabilités fait partie des obligations attendues. Un épisode comme PHP2Shell est exactement le genre de situation où l’on vous demandera de prouver ce que vous avez fait, et quand.

08L’avenir des sites web et de l’offre cyber pour les PME

PHP2Shell n’est pas un accident isolé. C’est le symptôme d’un modèle qui ne tient plus : le site web acheté une fois, livré, puis oublié.

• Un site n’est plus un achat, c’est un abonnement. Un site sans maintenance est un serveur ouvert sur Internet que personne ne surveille. Le coût réel d’un site, c’est sa création plus son entretien de sécurité, chaque mois.
• Les plateformes gérées vont gagner du terrain. Pour beaucoup de PME, un site vitrine hébergé sur une plateforme qui gère elle-même les mises à jour sera plus sûr qu’un WordPress installé en 2019 et jamais revu.
• L’offre cyber pour les petites structures va se développer. Veille sur les failles, vérification des mises à jour, audit simple de ce qui est exposé sur Internet : ces services, longtemps réservés aux grandes entreprises, deviennent nécessaires pour une PME de dix personnes. Et ils devront être expliqués en français, pas en jargon.

09Les opportunités à saisir

Une crise comme celle-ci a un avantage : elle donne une bonne raison de faire ce qu’on repoussait depuis des années. Pour une PME, voici ce qu’il y a à gagner.

• Faire l’inventaire de ce qui est en ligne. Site principal, ancien site, boutique, extranet, formulaire de devis, page d’un salon de 2021… Profitez de l’épisode pour lister tout ce qui est exposé sur Internet. Ce qui n’a pas de raison d’exister se ferme.
• Renégocier votre contrat de maintenance. C’est le bon moment pour demander à votre prestataire un engagement écrit : délai de correction des failles critiques, compte rendu après chaque intervention. Un prestataire sérieux accepte. Celui qui refuse vous donne une information précieuse.
• Faire de la sécurité un argument commercial. Vos clients et donneurs d’ordre posent de plus en plus la question. Pouvoir répondre « nous avons corrigé en 48 h et nous avons une procédure » vous distingue de concurrents qui ne savent pas de quoi on parle.
• Préparer votre dossier d’assurance cyber. Une procédure de mise à jour documentée, avec des dates, est exactement ce que les assureurs demandent. Ce que vous écrivez aujourd’hui servira à votre prochain renouvellement.
• Moderniser au lieu de rafistoler. Si votre site tourne sur une version de PHP abandonnée, la mise à jour forcée est l’occasion de repartir sur une base saine, plus rapide et plus simple à entretenir, plutôt que de colmater un site vieillissant.

10L’avis de Pavillon Noir

Le vrai problème n’est pas PHP. PHP a fait son travail : le correctif a été préparé sous embargo, en toute discrétion, avant l’annonce, et quand les détails ont fuité, sa publication a été avancée d’un jour, du 22 au 21 octobre. Le vrai problème, c’est le site orphelin : celui dont personne ne sait vraiment qui s’occupe.

Dans beaucoup de PME, le site a été fait par « le neveu », par une agence qui a fermé, ou par un freelance qu’on n’a plus rappelé depuis trois ans. Il tourne. Personne n’y touche. Jusqu’au jour où il sert à voler les données de vos clients.

Ma position est simple :

1. Chaque site doit avoir un responsable nommé. Une personne, pas « l’informatique ».
2. Chaque contrat de maintenance doit fixer un délai pour les failles critiques. Quelques jours au maximum, pas « dès que possible ».
3. Un site que personne n’entretient doit être fermé. Un vieux site oublié rapporte zéro et peut coûter très cher.

PHP2Shell sera oublié dans six mois. La prochaine faille, elle, arrivera. La seule différence entre les entreprises qui la subiront et les autres sera décidée maintenant : qui est responsable, et en combien de temps il agit.

11Petit glossaire

PHP

Langage de programmation qui fabrique les pages d’une grande partie des sites web, côté serveur. Vous ne le voyez pas, mais il travaille à chaque visite.

RCE

Remote Code Execution, exécution de code à distance : un attaquant fait exécuter ses propres commandes à votre serveur, depuis Internet.

CVE

Common Vulnerabilities and Exposures : le numéro d’identité unique d’une faille (ex. : CVE-2026-109618). Pratique pour parler de la même chose que votre prestataire.

CVSS

Note de gravité d’une faille, de 0 à 10. De 9,0 à 10, la faille est classée « critique ». PHP2Shell : 9,2 (CVSS version 4.0).

Correctif (patch)

Mise à jour qui supprime la faille. Ici, les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 de PHP.

Serveur piège (honeypot)

Faux serveur volontairement exposé par des chercheurs pour observer les attaques réelles sans mettre de vraies données en jeu.

Pavillon Noir — La cyber, sans le charabia.