PHP2Shell : couper son site sans perdre son SEO

🇬🇧 Read in English : PHP2Shell: closing a site without losing SEO

PHP2Shell désigne deux failles critiques du moteur PHP, corrigées le 21 octobre 2026, qui permettent de prendre la main sur un serveur sans mot de passe. Mettre à jour WordPress, Drupal, PrestaShop ou SPIP ne sert à rien contre elles : c’est PHP qu’il faut patcher, côté serveur. Si vous ne pouvez pas corriger tout de suite, couper est la bonne décision, mais la façon de couper se décide en quelques minutes et se paie pendant des mois. Code 503, robots.txt accessible, durée inférieure à une journée : voici la méthode, et pourquoi la sécurité et le référencement se traitent ensemble.

• PHP2Shell (CVE-2026-109618 et CVE-2026-109619, score CVSS v4.0 de 9,2 sur 10) touche PHP lui-même : mettre à jour son CMS ne protège de rien, tout site en PHP est concerné.
• Si vous coupez, renvoyez un code 503, jamais une page de maintenance en 200. C’est la seule réponse qui dit à Google « repassez plus tard » au lieu de « voici ma nouvelle page ».
• Laissez le robots.txt accessible en 200 et visez moins d’une journée : au-delà, Google traite la coupure comme définitive et retire les pages de l’index.
• Coupez le service vulnérable, pas tout le site. Un webmail ou un espace client s’arrête sans fermer la vitrine.
• Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. PHP 8.1 et antérieurs ne reçoivent plus de version corrective du projet PHP.

« On nous appelle pour remettre un site en ligne. On devrait nous appeler avant de l’éteindre : c’est là que tout se joue, et c’est le moment que personne ne prépare. »

— Olivier Watté, dit Oliver · fondateur de Kimoun

Qu’est-ce que PHP2Shell, et pourquoi mettre à jour son CMS ne suffit pas ?  

  Astuce

PHP2Shell est une faille du moteur PHP : seul celui qui gère le serveur peut la corriger, pas l’éditeur du CMS.

PHP est le langage qui génère les pages d’une très grande partie du web : WordPress, Drupal, Joomla, Magento, PrestaShop, SPIP, mais aussi des webmails, des outils de support ou des logiciels métiers. Les deux failles permettent d’exécuter du code à distance sans aucun mot de passe. Selon les chercheurs qui les ont analysées, la seconde laisse en plus fuiter des fragments de mémoire où peuvent traîner mots de passe, jetons ou clés d’API d’autres visiteurs.

Tous les modes d’exécution courants sont touchés, et le risque est maximal avec mod_php, où une requête anonyme peut déclencher l’attaque avant même qu’une ligne de votre site s’exécute. PHP a publié ses correctifs le 21 octobre à 14 h UTC, soit 10 h du matin en Guadeloupe. Des tentatives d’exploitation avaient été repérées avant la divulgation publique ; à ce stade, aucune compromission n’a été confirmée publiquement.

La différence avec WP2Shell est essentielle. En juillet, WP2Shell frappait le cœur de WordPress, et WordPress avait pu forcer la mise à jour de millions de sites. Cette fois, la faille est sous le CMS. Votre WordPress peut être parfaitement à jour, avec toutes ses extensions : si le serveur tourne sur une version vulnérable de PHP, le site est exposé.

Garder son site en ligne sans correctif : quels risques ?  

  Prudence

Laisser un site PHP vulnérable en ligne n’est pas un arbitrage entre deux options. Une faille à 9,2 sur 10, exploitable sans mot de passe, est scannée en masse dans les heures qui suivent sa publication. La question n’est pas de savoir si votre site sera trouvé, mais quand.

Il faut être direct : il n’existe pas de scénario raisonnable où l’on garde un site vulnérable en ligne en attendant mieux. Les robots qui cherchent les serveurs non corrigés ne visent personne en particulier. Ils balaient des plages entières d’adresses, testent, et gardent ce qui répond. Un petit site de Guadeloupe est exactement aussi intéressant qu’un grand site parisien : c’est une machine qui répond, et c’est tout ce qui compte.

Une prise de contrôle ne se voit pas. Elle ne casse rien, elle ne ralentit rien, et c’est précisément le problème : la plupart des victimes découvrent l’intrusion par un tiers, des semaines plus tard. Voici ce qui se joue réellement.

Votre réputation, et elle met des mois à revenir  

C’est le dommage le plus coûteux, et le plus sous-estimé. Un site compromis sert généralement à héberger des pages de spam, des redirections vers des sites douteux, ou des pages d’hameçonnage imitant une banque. Vos pages légitimes restent intactes : les nouvelles sont ajoutées dans des répertoires que personne ne regarde.

Google les trouve avant vous. Votre domaine se retrouve alors signalé comme trompeur, et les navigateurs affichent un écran rouge à vos visiteurs avant même d’ouvrir la page. Pour un hôtel ou une boutique, c’est l’équivalent d’un panneau « local insalubre » sur la vitrine. Le nettoyage technique prend quelques heures ; la levée de l’avertissement et le retour du classement prennent des semaines, parfois des mois.

Vos données clients, et votre responsabilité juridique  

Un accès au serveur donne accès à la base de données : fichier clients, adresses, commandes, numéros de téléphone, mots de passe. Avec la seconde faille, ce sont même les identifiants saisis par vos visiteurs qui peuvent fuiter, au moment où ils les tapent.

Une fuite de données personnelles n’est pas seulement un incident technique. Dès lors qu’un accès non autorisé est raisonnablement établi, et même sans preuve que les données aient été copiées, il s’agit d’une violation au sens du RGPD. Elle doit être notifiée à la CNIL dans les meilleurs délais et, si possible, sous 72 heures à compter du moment où vous en prenez connaissance, sauf si elle n’est pas susceptible d’engendrer un risque pour les personnes. Si le risque est élevé, vous devez en informer vos clients eux-mêmes. Et dans tous les cas, y compris sans notification, la violation doit être consignée dans un registre interne.

Écrire à ses clients pour leur annoncer que leurs données ont circulé est une épreuve dont peu d’entreprises se remettent sans dégâts. Les sanctions récentes de la CNIL ne portent d’ailleurs pas tant sur le défaut de notification que sur le manque de sécurité en amont et sur une information des personnes bâclée en aval.

Vos ressources, détournées à vos frais  

Un serveur compromis est une ressource gratuite pour qui le contrôle. Les usages classiques : envoi de courriels frauduleux depuis votre domaine, ce qui le fait inscrire sur les listes noires et empêche ensuite vos propres messages d’arriver ; minage de cryptomonnaie, qui sature le processeur ; ou participation à des attaques contre d’autres sites, avec votre adresse IP comme signature.

Vous payez la bande passante, vous payez le calcul, et c’est votre nom qui apparaît dans les journaux des victimes suivantes.

Et surtout : les autres services de la même machine  

C’est le risque le moins connu, et souvent le plus grave. Un site vulnérable ne met pas seulement ce site en danger.

Sur un hébergement mutualisé, des dizaines de sites partagent le même serveur. Une prise de contrôle sur l’un d’eux ouvre la voie à l’exploration des répertoires voisins, à la lecture de leurs fichiers de configuration, et donc à leurs bases de données. Vos accès peuvent être compromis sans que votre site ait eu le moindre défaut.

Même sur un serveur dédié, le danger existe. Un minage de cryptomonnaie qui accapare le processeur et la mémoire fait tomber les autres applications de la machine, les unes après les autres : votre messagerie, votre espace client, votre outil de facturation. L’attaquant n’a pas besoin de les compromettre, il lui suffit de les priver de ressources. Et si vos services partagent la même base de données ou le même réseau interne, la compromission se propage d’elle-même.

C’est la raison pour laquelle nous avons traité nos sept applications en quelques heures, et non en quelques jours : une seule application vulnérable suffisait à mettre les six autres en danger.

Le parc exposé est considérable  

Le problème est massif, y compris outre-mer. En septembre, notre Observatoire relevait que 35 % des sites ultramarins dont la version de PHP était lisible tournaient sur une version en fin de vie. Pour ces sites-là, attendre un correctif ne mènera nulle part : il n’en viendra pas.

La seule question qui vaille devient alors : corriger maintenant, migrer, ou couper proprement le temps de s’organiser. Les trois réponses sont acceptables. Ne rien faire ne l’est pas.

Comment couper son site sans perdre son référencement ?  

  Astuce

Coupez le moins possible, le moins longtemps possible, et dites-le à Google avec un code 503.

Si votre site ne peut pas être corrigé tout de suite, voici l’ordre que nous recommandons :

1. Couper seulement le service vulnérable. Un webmail, un formulaire ou un espace client peuvent être arrêtés sans fermer le site vitrine. C’est ce que permettait notre coupure ciblée du webmail.
2. Renvoyer un code 503 sur les pages fermées. Il signifie « indisponible pour l’instant, repassez plus tard », et Google ignore le contenu de la page de maintenance.
3. Ajouter un en-tête Retry-After pour indiquer aux robots quand revenir.
4. Laisser le fichier robots.txt accessible, en code 200. Un robots.txt en erreur serveur est traité à part par Google et peut suspendre l’exploration de tout le site.
5. Viser moins d’une journée. Si la coupure doit durer, servez une version statique du site, comme le suggère Google, plutôt qu’une page vide.
6. Surveiller la réouverture pendant quelques jours dans Google Search Console (pages indexées, statistiques d’exploration) et dans Bing Webmaster Tools.

Concrètement, sur un serveur Nginx, une coupure propre tient en quelques lignes : on renvoie 503 sur tout le site, on laisse passer le robots.txt, et on indique quand revenir.

location / {
    return 503;
}

# Le robots.txt doit rester accessible en 200 : un robots.txt
# en erreur peut suspendre l'exploration de tout le site.
location = /robots.txt {
    try_files $uri =404;
}

error_page 503 @maintenance;
location @maintenance {
    add_header Retry-After 3600 always;
    try_files /maintenance.html =503;
}

Ces réglages se font au niveau du serveur ou du proxy, pas dans le CMS. Une extension « mode maintenance » mal configurée renvoie souvent un code 200 : c’est précisément l’erreur à éviter.

Reste à comprendre pourquoi ce détail technique pèse autant. C’est l’objet de la section suivante.

Pourquoi le code HTTP décide de ce que Google retient  

Le 21 octobre, des centaines d’organisations ont préféré couper. En France, tous les sites des préfectures ont été mis hors ligne à la demande de l’ANSSI, tout comme des sites publics aux Pays-Bas et en Finlande. Au Québec, la STM, la SAQ et la SAAQ ont verrouillé leurs sites ; côté fédéral, le gouvernement du Canada a fermé plusieurs services sur recommandation du Centre canadien pour la cybersécurité.

Pour une préfecture, l’enjeu de référencement est secondaire. Pour une TPE, un hôtel ou une boutique en ligne, il ne l’est pas. Ce que Google retient d’une coupure dépend surtout du code HTTP que le serveur lui renvoie pendant qu’elle dure :

La durée compte autant que le code. John Mueller, de Google, l’a résumé ainsi : un code 503 est la bonne réponse pour une interruption d’environ une journée, mais au bout de quelques jours Google le traite comme un état permanent et commence à retirer les pages de son index. Même une coupure propre laisse une trace : Google réduit son rythme d’exploration en proportion des pages en erreur, et ne le remonte que progressivement.

Les moteurs de réponse ne font pas exception, et le risque y est plus durable. Ils s’appuient sur les mêmes index ou sur leurs propres robots, comme Labrador pour ChatGPT. Une page « maintenance » servie comme du vrai contenu peut finir résumée dans une réponse IA, à la place de votre offre.

La différence avec Google est qu’un index génératif ne se rafraîchit pas au même rythme. Quand Google recrawle une page rouverte en quelques jours, une réponse d’IA peut continuer à citer ce qu’elle avait retenu pendant des semaines : votre page de maintenance, ou pire, une version piratée de votre site. C’est tout l’enjeu du référencement dans les réponses d’IA : ce qui est capté à un instant donné vous suit longtemps. Nos premiers relevés d’AI Overview sur 189 sites d’outre-mer montraient déjà que les sources citées changent lentement.

Comment avons-nous traité PHP2Shell sur nos serveurs ?  

Cette méthode, nous l’appliquons d’abord à nous-mêmes. Voici comment nous avons traité nos propres serveurs le 21 octobre, et pourquoi nous n’avons eu à couper qu’un seul service.

Notre intervention a suivi cinq étapes. Aucune ne demandait de génie ; toutes demandaient de savoir précisément ce qui tournait.

1. Inventaire. Aucun PHP n’est installé directement sur nos trois serveurs de production : tout tourne en conteneurs Docker. Vérifier la version de PHP sur le serveur ne montrait donc rien. Nous avons relevé la version conteneur par conteneur, puis croisé avec les domaines publics. Résultat : 7 applications PHP exposées sur Internet, toutes vulnérables, de PHP 8.1 à 8.5.9. Les sites statiques et les applications en Node, Python ou Go n’étaient pas concernés.
2. Arbitrage. Toutes les applications ne méritaient pas la même réponse. Une a été supprimée, son utilité ne justifiant plus le risque. Un vieux PrestaShop en PHP 8.1, lui, ne pouvait pas être corrigé en l’état : il a fallu le migrer en urgence vers une version maintenue. Les cinq autres ont été corrigées. En attendant, une coupure ciblée restait possible : arrêter le webmail vulnérable tout en gardant la réception et l’envoi des e-mails.
3. Correction. Le correctif ne touchait aucune ligne de code applicatif : il suffisait de changer l’image de base des conteneurs, en figeant la version corrigée plutôt qu’une étiquette « flottante » dont on ne sait jamais à quelle version elle correspond. Pour un logiciel de messagerie dont l’éditeur n’avait pas encore publié de version corrigée, nous avons reconstruit l’image en remplaçant uniquement les paquets PHP, en vérifiant que les modules restaient strictement identiques.
4. Vérification. Chaque image a été construite et lancée en local avec sa base de données : santé du service, page d’accueil, connexion, modules métier. Quand un comportement paraissait suspect, le même test a été rejoué sur l’ancienne image pour distinguer une régression d’un comportement préexistant.
5. Livraison. Pour deux applications, la plateforme de déploiement ne suivait pas la branche principale du dépôt. Y pousser le correctif n’aurait rien changé en production, alors que tout le monde l’aurait cru corrigée. Pour une autre, l’image utilisée en production était définie par un réglage de la plateforme, pas par le dépôt.

Ce que cet épisode nous a appris (et ce qu’il faut demander à votre prestataire)  

Ces leçons valent pour tout site en PHP, quel que soit le prestataire qui le gère :

• L’inventaire se fait là où PHP tourne vraiment. En conteneurs, le serveur hôte ne montre rien : il faut regarder dans chaque conteneur.
• Un dépôt à jour ne prouve rien. Seule compte la version réellement déployée en production.
• Une étiquette « latest » donne une fausse sécurité. Sans téléchargement explicite, rien ne se met à jour.
• Une version de PHP qui n’est plus maintenue n’aura jamais de correctif. Il faut migrer ou couper.
• Un correctif se vérifie sur l’application qui tourne, pas seulement dans le code.

Pourquoi un prestataire local et réactif fait la différence ?  

Le correctif est tombé à 10 h, heure de Guadeloupe. Pour un prestataire installé ici, c’était une matinée de travail ordinaire, pas une nuit d’astreinte depuis un autre fuseau horaire. Nos sept applications étaient traitées dans la journée, quelques heures après la publication du correctif. Mais l’heure n’est pas le plus important : l’essentiel de notre intervention a consisté à savoir. Savoir où tournait PHP, quelle version était réellement déployée, quelle application méritait d’être corrigée et laquelle pouvait disparaître.

Cette dernière décision ne se prend pas à distance, ni par un outil. Migrer une boutique en urgence, mais supprimer une autre application plutôt que d’y passer la journée, suppose de connaître leur utilité réelle. C’est le cœur de l’infogérance : un humain qui connaît le parc, qui décide et qui vérifie. Nous l’écrivions déjà en septembre : le problème n’est pas l’outil, c’est l’absence de pilotage.

C’est la troisième alerte majeure en trois mois, après WP2Shell en juillet et l’attaque Shai-Hulud en août. La question à se poser aujourd’hui est simple : qui, chez vous, a vérifié la version de PHP de votre site depuis le 21 octobre ? Si personne ne sait répondre, c’est que personne ne pilote. Notre offre d’ hébergement et d’infogérance existe pour que cette question ait toujours une réponse.

Et la réponse technique ne suffit pas. Un site corrigé mais désindexé, ou cité de travers par une IA pendant des semaines, reste un site qui ne rapporte rien. C’est pourquoi nous traitons les deux faces ensemble : le serveur d’un côté, la visibilité dans Google et dans les réponses d’IA de l’autre. Une alerte de sécurité est aussi un événement de référencement, et peu de prestataires regardent les deux à la fois.