Votre site affiche des pages que vous n'avez jamais écrites, Google le signale comme dangereux, ou votre hébergeur vient de vous envoyer un e-mail inquiétant. Si votre site tourne sous WordPress, PrestaShop, Joomla, Drupal ou tout autre outil écrit en PHP, la faille PHP2Shell publiée le 21 octobre 2026 est peut-être passée par là.
Ce guide s'adresse aux dirigeants et responsables de site qui ne sont pas développeurs. Il dit quoi faire, dans quel ordre, pendant les 48 premières heures après un piratage de site lié à PHP2Shell. Pas de jargon inutile : quand un terme technique est nécessaire, on l'explique.
Une précision d'abord, pour ne pas ajouter de la panique à la panique : être exposé à la faille ne veut pas dire être piraté. Beaucoup de sites seront corrigés à temps. Mais si vous voyez l'un des signes décrits plus bas, chaque heure compte.
La faille PHP2Shell en deux minutes
PHP est le langage qui fait tourner près de 70 % des sites web dont on connaît la technologie, d'après les chiffres W3Techs repris par Tenable. WordPress, PrestaShop, Joomla, Drupal et Magento reposent tous dessus.
Le 21 octobre 2026, l'équipe qui maintient PHP a publié en urgence des correctifs pour deux failles, CVE-2026-109618 et CVE-2026-109619, rassemblées sous le nom PHP2Shell. Leur gravité est notée 9,2 sur 10. Elles permettent à un inconnu de prendre le contrôle du serveur qui héberge votre site, sans mot de passe, en lui envoyant une simple requête bien préparée.
Deux détails rendent la situation sérieuse :
- La faille est dans PHP lui-même, pas dans une extension. Un site parfaitement entretenu est exposé tant que PHP n'est pas mis à jour.
- Les détails ont fuité la veille sur un forum, et Cloudflare a observé les premières attaques le 21 octobre à 7 h 43 (heure UTC), plusieurs heures avant la publication du correctif.
Le CERT-FR, l'équipe de réponse aux incidents de l'État, a publié une alerte le jour même. Sa recommandation : isoler les serveurs concernés, puis passer sur une version maintenue de PHP.
Les signes qu'un site PHP a été piraté
Un attaquant qui prend la main sur un serveur cherche en général à rester discret et à rentabiliser son accès. Voici ce que vous pouvez remarquer sans compétence technique :
- Des pages inconnues apparaissent quand vous tapez
site:votresite.frdans Google (souvent en anglais, en japonais, ou sur des produits pharmaceutiques). - Vos visiteurs sont redirigés vers un autre site, parfois seulement sur mobile ou seulement quand ils arrivent depuis Google.
- Votre navigateur ou Google affiche un avertissement « site dangereux ».
- Un compte administrateur que personne ne connaît est apparu dans votre WordPress ou votre PrestaShop.
- Le site est devenu lent, ou affiche des erreurs qu'il n'affichait pas.
- Votre hébergeur vous signale une activité anormale, des envois d'e-mails massifs ou une consommation inhabituelle.
Aucun de ces signes n'est une preuve. Ensemble, ou si l'un d'eux apparaît depuis le 20 octobre, ils justifient de déclencher la suite.
Avant d'agir : la checklist des 15 minutes
Avant de toucher à quoi que ce soit, rassemblez ces éléments. Ils vous seront demandés par tous les interlocuteurs qui vont vous aider.
- L'adresse de connexion et les identifiants de votre espace client chez l'hébergeur
- Le nom de votre hébergeur et votre type d'offre (mutualisé, VPS, serveur dédié)
- Les coordonnées de la personne ou de l'agence qui a créé ou maintient le site
- La date à laquelle vous avez remarqué le problème, et des captures d'écran
- La liste des données personnelles que le site stocke : comptes clients, commandes, formulaires de contact
- La date de votre dernière sauvegarde connue
Les 48 premières heures, étape par étape
Heure 1 : prévenir et couper. Appelez votre hébergeur ou votre prestataire. Demandez que le site soit mis en maintenance ou coupé. C'est désagréable, surtout pour une boutique en ligne, mais un serveur compromis peut servir à voler les données de vos clients ou à attaquer d'autres sites pendant qu'il reste en ligne.
Heures 1 à 4 : conserver les preuves. Demandez une copie complète du site et de sa base de données, ainsi que les journaux du serveur (les « logs », qui enregistrent chaque visite). Ne supprimez rien. Ces éléments servent à comprendre ce qui s'est passé, à porter plainte et, le cas échéant, à répondre à la CNIL.
Heures 4 à 24 : se faire aider. Le service public 17Cyber, porté par la gendarmerie, la police et Cybermalveillance.gouv.fr, est gratuit et ouvert en permanence. Il vous oriente selon le type d'attaque et peut vous mettre en relation avec un prestataire référencé. Vous pouvez aussi porter plainte : c'est utile pour votre assurance.
Avant la 72e heure : la question des données personnelles. Si votre site stocke des données de clients (noms, adresses, e-mails, historiques de commande) et qu'elles ont pu être consultées, le RGPD vous impose de notifier la CNIL dans les 72 heures après en avoir pris connaissance avec une certitude raisonnable. Une notification partielle dans les délais vaut mieux qu'une notification complète en retard : l'article 33 du RGPD autorise à la compléter ensuite. Le formulaire est sur le site de la CNIL.
Heures 24 à 48 : nettoyer, puis seulement remettre en ligne. La remise en ligne ne doit se faire qu'avec PHP en version corrigée (8.2.35, 8.3.36, 8.4.27, 8.5.12 ou plus récente) et tous les mots de passe changés : administration du site, base de données, accès FTP ou SSH, espace client de l'hébergeur.
Le piège qu'on voit régulièrement : restaurer la sauvegarde et repartir
Le réflexe le plus naturel est aussi le plus risqué.
Symptôme. Le site affiche des pages piratées. Le gestionnaire restaure la sauvegarde de la semaine précédente, tout semble rentrer dans l'ordre. Dix jours plus tard, les pages indésirables réapparaissent.
Diagnostic. Un attaquant qui a eu la main sur un serveur dépose presque toujours une « porte dérobée » : un petit fichier caché qui lui permet de revenir. Si cette porte a été posée avant la date de la sauvegarde, la restauration la remet en place. Et si PHP n'a pas été mis à jour, la faille d'origine reste ouverte de toute façon.
Correctif. Avant toute restauration : mettre PHP à jour, comparer la sauvegarde avec une version saine connue, chercher les fichiers ajoutés ou modifiés et les comptes inconnus. Sur un site très infecté, reconstruire à partir des contenus (textes, images, produits) plutôt que des fichiers est souvent plus rapide que de traquer chaque porte dérobée. Une boutique avec des comptes clients et des commandes demande plus de vérifications qu'un site vitrine.
Trois options pour la suite, comparées
| Nettoyer et garder le site | Reconstruire sur le même outil | Migrer hors de PHP | |
|---|---|---|---|
| Délai indicatif | Quelques jours | Une à trois semaines | Quelques semaines, par étapes |
| Risque de réinfection | Élevé si une porte dérobée échappe au nettoyage | Faible | Faible |
| Mises à jour d'urgence à l'avenir | Toujours nécessaires | Toujours nécessaires | Beaucoup plus rares |
| Conservation du référencement | Oui | Oui, avec redirections | Oui, avec redirections |
| Pertinent si | Site récent, bien entretenu, piratage limité | Site ancien mais adapté à vos besoins | Site ancien, extensions abandonnées, lassitude des urgences |
Pourquoi on déconseille de payer un « nettoyage express » sans mise à jour de PHP
Des offres de nettoyage en quelques heures vont fleurir dans les jours qui viennent. Certaines sont sérieuses. Mais un nettoyage qui ne commence pas par la mise à jour de PHP, et qui ne s'accompagne pas d'une recherche de portes dérobées, revient à repeindre une maison dont la porte d'entrée est restée ouverte.
Posez trois questions à tout prestataire : quelle version de PHP sera installée, comment il vérifie l'absence de porte dérobée, et ce qu'il vous remet comme compte rendu. S'il ne sait pas répondre aux trois, cherchez ailleurs.
Et après PHP2Shell ?
Une fois l'urgence passée, la question de fond reste entière : voulez-vous continuer à dépendre de mises à jour d'urgence chaque fois qu'une faille touche PHP ou une extension ? Pour beaucoup de sites vitrines et de petites boutiques, la réponse honnête est oui, à condition d'avoir quelqu'un qui surveille. Pour d'autres, c'est le moment de passer à une architecture où les pages publiques ne dépendent plus d'un serveur PHP. Nous avons détaillé ce choix dans notre article sur l'arbitrage entre patcher et migrer, et les solutions possibles dans notre panorama des alternatives à WordPress.
L'agence Platane (https://platane.io) aide des TPE et PME à diagnostiquer leur exposition à PHP2Shell, à chercher les traces d'un piratage et à migrer leur site vers une architecture sans PHP, hébergée en France. La démarche est décrite sur notre page Migration PHP.
