PHP2Shell : ce que votre site vitrine doit vérifier cette semaine

Ce qui s'est passé entre le 17 et le 26 octobre 2026

Le 21 octobre 2026, le projet PHP a publié des correctifs pour deux failles critiques, CVE-2026-109618 et CVE-2026-109619, baptisées PHP2Shell, qui permettent d'exécuter du code à distance sur un serveur sans disposer d'identifiants. Les versions corrigées sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. L'exploitation a commencé avant même la publication officielle.

La chronologie compte, car elle explique pourquoi l'alerte ne relève pas d'un simple « bulletin de plus ». Le 17 octobre, le système de pièges à attaques d'Amazon (MadPot) a enregistré une première tentative d'exploitation, quatre jours avant la divulgation publique. Le 20 octobre, des détails ont fuité sur les réseaux sociaux, avant la date de divulgation initialement prévue du 22 octobre ; la société de sécurité watchTowr a confirmé que les failles étaient réelles et publié une foire aux questions. Le 21 octobre à 14 h UTC, PHP a livré les versions corrigées, et watchTowr a observé des attaques le jour même. Le même jour, le CERT-FR de l'ANSSI a diffusé l'alerte CERTFR-2026-ALE-014, relayée dans la presse spécialisée française le lendemain. Le 26 octobre, la CISA américaine a ajouté CVE-2026-109618 à son catalogue des vulnérabilités activement exploitées (KEV).

Il faut rester précis sur ce que l'on sait. Plusieurs acteurs (Amazon, watchTowr, Cloudflare, HKCERT à Hong Kong, le Centre canadien pour la cybersécurité) parlent d'exploitation ou de tentatives d'exploitation. D'autres sont plus nuancés : Wiz indiquait le 27 octobre ne pas avoir observé d'attaque complète réussie dans sa télémétrie, et Unit 42 a retiré le 23 octobre une affirmation concernant une agence gouvernementale européenne. La lecture raisonnable pour un dirigeant est donc la suivante : le code d'exploitation existe, il est déclenchable par une seule requête non authentifiée, des tentatives sont avérées, et chaque jour sans mise à jour augmente l'exposition. Cet article vous explique comment le vérifier et le traiter, que votre site tourne sur Joomla, WordPress, Drupal ou PrestaShop.

Pour mesurer l'ampleur, un chiffre : le service de vérification gratuit de Brandefense a lu une version de PHP sur 3 532 sites entre le 21 et le 25 octobre 2026, et 59 % d'entre eux (2 071 sites) affichaient une version antérieure aux correctifs. L'échantillon n'est pas aléatoire, puisque les visiteurs ont choisi les sites testés, et seuls 12 % environ des sites contrôlés exposent leur version. Mais l'ordre de grandeur est clair : une majorité de sites lisibles n'était pas à jour dans la semaine qui a suivi l'alerte.

Pourquoi un site vitrine est concerné, même sans formulaire ni espace client

Tout serveur qui exécute PHP pour répondre à des requêtes web est concerné, qu'il héberge un site vitrine de dix pages ou une plateforme complexe. PHP précise lui-même que cela couvre PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Il n'est pas nécessaire que le site propose un formulaire, un compte utilisateur ou une zone sensible.

C'est ce qui distingue cette alerte d'une faille d'extension WordPress ou de module Joomla. Dans ces cas, l'exposition dépend d'un composant précis que vous pouvez désactiver ou retirer. Ici, la faiblesse se situe dans l'interpréteur lui-même : les deux failles exploitent la gestion de la mémoire pendant le traitement d'une requête. La première (CVE-2026-109618) provient d'une corruption mémoire lors du nettoyage d'une requête interrompue. La seconde (CVE-2026-109619) provient d'un état global périmé, qu'une requête ultérieure peut réutiliser sur le même processus de travail. Aucune des deux ne dépend de la qualité du code de votre thème ou de vos extensions.

PHP classe le mode Apache avec mod_php comme le plus risqué, car une requête non authentifiée peut déclencher l'attaque avant que le moindre code applicatif ne s'exécute. Dans ce cas, ni votre CMS à jour, ni votre extension de sécurité ne peuvent intervenir : ils ne sont tout simplement pas encore chargés. Un site vitrine hébergé sur un serveur mutualisé ou sur un VPS ancien, dont la configuration n'a pas bougé depuis des années, coche souvent cette case sans que personne ne le sache.

Un second point surprend les dirigeants : les conséquences ne se limitent pas au site. Une exécution de code sur un serveur web peut servir à lire les fichiers de configuration (donc les identifiants de base de données), à déposer une porte dérobée, à envoyer des courriels frauduleux depuis votre domaine ou à rebondir vers d'autres sites hébergés sur la même machine. Pour une entreprise qui gère plusieurs sites sur un même hébergement, c'est précisément la logique d'une gestion de parc : un seul serveur non corrigé expose l'ensemble.

Quelles versions de PHP sont corrigées, lesquelles ne le seront jamais

Quatre branches de PHP disposent d'un correctif officiel : 8.2 (à partir de la 8.2.35), 8.3 (8.3.36), 8.4 (8.4.27) et 8.5 (8.5.12). Les branches 8.1 et antérieures ne reçoivent plus de correctifs de la part du projet PHP, qui a seulement publié des rétroportages minimaux pour les compilations depuis les sources. Pour ces branches, la solution durable est la migration.

Dates issues de la page des versions prises en charge de php.net, lue le 9 novembre 2026, et des annonces du projet PHP du 21 octobre 2026.

Deux nuances opérationnelles méritent d'être connues. Premièrement, les distributions Linux et les éditeurs de support étendu ont reçu les correctifs avant la publication officielle ; leurs paquets peuvent contenir le correctif sous un numéro de version plus ancien. Un site qui affiche « PHP 8.1.x » n'est donc pas automatiquement vulnérable s'il tourne sur une distribution qui maintient cette branche, mais c'est à votre hébergeur de le confirmer par écrit. Deuxièmement, la mise à jour du paquet ne suffit pas : les processus PHP en mémoire doivent être redémarrés pour que le correctif prenne effet. Une réponse d'hébergeur du type « nous avons patché » sans mention du redémarrage est incomplète.

Il y a enfin le cas, plus fréquent qu'on ne le croit, des sites encore sur PHP 7.4 ou 8.0 parce qu'une extension ou un thème ancien ne fonctionne pas autrement. Ils cumulent un interpréteur sans support depuis plusieurs années et une dette technique qui rend la montée de version coûteuse. Nous avons détaillé la logique de ces échéances dans notre billet sur la fin de vie de PHP 8.2 au 31 décembre 2026 : PHP2Shell rend simplement la date butoir plus pressante.

Vérifier en moins d'une heure ce que fait réellement votre site

Trois informations suffisent pour établir votre exposition : la version exacte de PHP utilisée par chaque site, le mode d'exécution (Apache mod_php, PHP-FPM ou autre) et la confirmation écrite de l'hébergeur que le correctif est appliqué et les processus redémarrés. Le premier point se lit dans l'administration de votre CMS, les deux autres demandent un échange avec l'hébergeur.

Pour la version, chaque CMS l'affiche à un endroit différent. Sous Joomla, elle figure dans Système, Informations système. Sous WordPress, dans Outils, Santé du site, onglet Infos, rubrique Serveur. Sous Drupal, dans Rapports, État du système. Sous PrestaShop, dans Paramètres avancés, Informations. Notez le numéro complet (par exemple 8.3.34 et non « 8.3 »), car c'est le numéro de correctif qui détermine si vous êtes avant ou après le 8.3.36.

Attention à deux pièges. Le premier : certains hébergements mutualisés permettent de choisir la version de PHP site par site dans le panneau de contrôle, et un ancien site secondaire, oublié, peut rester sur une branche abandonnée. Le second : l'en-tête de réponse HTTP qui révèle la version de PHP est souvent masqué par mesure d'hygiène, ce qui explique que seuls 12 % des sites contrôlés par Brandefense affichaient leur version. Un outil externe ne remplace donc pas une vérification côté serveur.

Pour l'hébergeur, posez des questions fermées, auxquelles on répond par oui ou non et une date : quelle version exacte de PHP exécute mon compte ? Le correctif PHP2Shell (CVE-2026-109618 et CVE-2026-109619) est-il appliqué, à quelle date ? Les processus ont-ils été redémarrés après la mise à jour ? Si ma branche n'est plus supportée, quel est votre plan et sous quel délai ? Conservez les réponses : elles constituent votre trace de diligence en cas d'incident, et elles seront utiles pour les obligations de documentation que nous évoquons plus bas.

Si vous gérez plusieurs sites, faites cet inventaire dans un seul tableau (site, hébergeur, version de PHP, date de vérification, responsable). C'est un exercice de quelques heures qui fait aussi apparaître les sites orphelins : ceux dont personne ne se souvient, hébergés chez un ancien prestataire, et qui sont souvent les premiers à tomber. Notre offre d'infogérance de parc digital repose précisément sur ce type d'inventaire tenu à jour.

Mesures provisoires : ce qu'elles font, et pourquoi elles ne remplacent pas la mise à jour

Aucune configuration ne neutralise entièrement les deux failles : PHP l'écrit lui-même, la seule vraie correction est la mise à jour de l'interpréteur. Les mesures provisoires servent uniquement à réduire le risque pendant les heures ou les jours où la mise à jour est impossible, par exemple le temps de tester la compatibilité de votre site.

Les recommandations convergentes du CERT-FR, de l'organisme néerlandais NCSC-NL et de PHP sont les suivantes : désactiver la fonction de suivi de progression des téléversements (session.upload_progress.enabled=0) puis redémarrer les processus, réduire la valeur de post_max_size, et sur PHP 8.5 désactiver les traces d'appel sur erreur fatale (fatal_error_backtraces=0). Le CERT-FR ajoute le blocage des requêtes dont le type de contenu est multipart lorsque le site n'en a pas besoin. Ces réglages doivent être testés sur un environnement de préproduction, car ils peuvent perturber les formulaires avec envoi de fichiers.

Le pare-feu applicatif (WAF) constitue une couche supplémentaire utile. Cloudflare a déployé, dès le 21 octobre, des règles dédiées activées par défaut, y compris sur les offres gratuites. Mais un WAF ne protège que si votre serveur n'accepte du trafic web que depuis ce WAF ; si l'adresse IP d'origine de votre serveur reste joignable directement, un attaquant contourne la protection. Et il ne remplace pas la mise à jour : il bloque des vecteurs connus, pas toutes les variantes à venir.

Enfin, le centre national de cybersécurité britannique recommande de mettre hors ligne tout système qui ne peut pas être corrigé immédiatement. Plusieurs services publics français ont d'ailleurs coupé certains sites par précaution après l'alerte du CERT-FR. Pour un site vitrine qui ne génère pas de chiffre d'affaires direct, une page de maintenance temporaire de quelques heures coûte souvent moins cher qu'une compromission. Pour une boutique en ligne, la décision est plus délicate et mérite un arbitrage chiffré avec votre prestataire.

PrestaShop, Joomla, WordPress, Drupal : la compatibilité PHP détermine votre marge de manœuvre

Corriger PHP2Shell revient à monter de version de PHP, et chaque CMS pose ses limites. PrestaShop 8 est plafonné à PHP 8.1, branche sans correctif, tandis que Drupal 11 exige PHP 8.3 et que WordPress 7.0 recommande PHP 8.4 ou 8.5. Selon votre CMS, le correctif est donc une opération d'hébergement de quelques minutes ou un chantier de migration.

PrestaShop est le cas le plus tendu. La documentation officielle du projet indique que les versions 8.0 à 8.2 ne prennent pas en charge PHP 8.2 ou supérieur ; leur plafond est PHP 8.1, qui n'est plus supportée depuis le 31 décembre 2025. Pour PrestaShop 9, la documentation liste PHP 8.1 à 8.3 pour la 9.0 et 8.1 à 8.4 pour la 9.1, avec une recommandation de PHP 8.5 sur la page des prérequis. Une boutique en PrestaShop 8 est donc piégée : rester sur PHP 8.1 (sans correctif officiel, donc dépendant du rétroportage de votre hébergeur) ou monter de version de PHP au risque de pannes de modules, voire de pages en erreur 500 sur des versions plus anciennes de la 1.7. La sortie durable est la migration vers PrestaShop 9, à planifier avec un test complet du tunnel de commande. Notre page maintenance PrestaShop détaille cette approche.

Joomla suit un calendrier plus favorable. Joomla 5 a vu la fin de son support correctif régulier le 13 octobre 2026, avec des correctifs de sécurité jusqu'au 12 octobre 2027, et Joomla 6.2 est sorti le même jour. Les sites en Joomla 5 peuvent généralement passer en PHP 8.3 ou 8.4 après test des extensions tierces, ce qui règle le problème PHP2Shell sans toucher au CMS.

WordPress est le plus souple : WordPress 7.0 (sorti le 20 mai 2026) fonctionne dès PHP 7.4 et recommande PHP 8.4 ou 8.5. Le véritable obstacle est la compatibilité des extensions et des thèmes : une extension abandonnée peut casser sur PHP 8.3. C'est le moment de dresser la liste des extensions sans mise à jour depuis plus de douze mois.

Drupal impose un chantier plus lourd : Drupal 10 arrive en fin de vie le 9 décembre 2026, et Drupal 11 requiert PHP 8.3. Si votre site est encore en Drupal 9 ou en Drupal 10 sur PHP 8.1, la migration de PHP et celle du CMS doivent être pensées ensemble ; nous l'avons détaillé dans notre billet sur la fin de vie de Drupal 10.

Une règle générale vaut pour les quatre CMS : on ne change pas de version de PHP en production sans sauvegarde restaurable et sans test préalable sur une copie. La rapidité n'excuse pas l'improvisation, et un site cassé par une montée de version précipitée coûte aussi cher qu'un site compromis.

Et si votre site avait déjà été visité ? Reconnaître une compromission et réagir

Un site exploité via PHP2Shell ne montre pas forcément de symptôme visible : l'attaquant cherche souvent la discrétion pour conserver son accès. Les signes à rechercher sont des fichiers PHP récents dans des répertoires de contenu ou de cache, des processus inhabituels lancés par le serveur web, des courriels sortants anormaux, des redirections ou du contenu injecté et des connexions d'administration inconnues.

Le premier réflexe est de ne pas « nettoyer » avant d'avoir conservé les journaux. Les journaux d'accès et d'erreurs du serveur, sur la période du 17 octobre à aujourd'hui, permettent de repérer des requêtes inhabituelles (par exemple des requêtes multipart vers des URL qui n'attendent pas de téléversement) et de dater une éventuelle intrusion. Demandez-en une copie à votre hébergeur avant toute restauration, car ils sont parfois conservés peu de temps.

Le second réflexe est de raisonner en niveaux. Si rien d'anormal n'apparaît et que PHP est maintenant corrigé, un contrôle d'intégrité des fichiers du CMS (comparaison avec les fichiers d'origine) et un changement des mots de passe d'administration et de base de données suffisent le plus souvent. Si un fichier suspect apparaît, il faut isoler le site, restaurer depuis une sauvegarde antérieure au 17 octobre après vérification, remplacer tous les secrets (mots de passe, clés d'API, clés de sel du CMS) et corriger la cause avant de remettre en ligne. Notre service de dépannage de site internet intervient précisément dans ce scénario, et la qualité de vos sauvegardes y est décisive.

Reste la question réglementaire. Si des données personnelles ont pu être consultées ou exfiltrées (base de contacts, messages de formulaire, comptes clients), le RGPD impose en principe de notifier la CNIL dans un délai de 72 heures après avoir pris connaissance de la violation, sauf si elle est peu susceptible d'engendrer un risque pour les personnes. Même lorsque la notification n'est pas requise, l'article 33 du RGPD demande de documenter l'incident en interne. Les entités soumises à la directive NIS2 ont en plus leurs propres délais de signalement ; un échange avec votre responsable de la conformité s'impose.

Ce qu'un contrat de maintenance doit prévoir pour que la prochaine alerte ne vous prenne pas de court

Un contrat de maintenance sérieux couvre l'interpréteur PHP et pas seulement le CMS : il fixe qui surveille les alertes, dans quel délai le correctif est appliqué et qui supporte le coût d'une montée de version. Le cas PHP2Shell est un révélateur, parce qu'il tombe souvent entre deux responsabilités : l'hébergeur gère PHP, l'agence gère le site, et chacun suppose que l'autre agit.

Voici les clauses qui font la différence. Le périmètre doit nommer explicitement la version de PHP et la configuration du serveur, ou préciser que l'hébergeur en est responsable avec une obligation de notification. Le délai de traitement des alertes critiques doit être chiffré : une alerte du CERT-FR classée critique doit déclencher une évaluation sous 24 heures ouvrées et une correction ou une mesure de contournement sous 72 heures, par exemple. La clause de montée de version doit dire si elle est incluse dans le forfait, facturée au temps passé ou traitée en projet séparé. Enfin, le contrat doit prévoir la restauration testée : une sauvegarde jamais restaurée n'est pas une sauvegarde.

Sur les montants, voici des repères de marché, à titre purement indicatif et issus de grilles d'agences relevées en octobre 2026. Une maintenance de site vitrine se situe de 60 à 400 € HT par mois et par site selon le niveau de service, avec la surveillance des alertes comprise dans les formules hautes. Une intervention hors forfait se facture de 70 à 95 € HT de l'heure, et le tarif journalier d'un développeur indépendant ou d'une agence s'établit entre 450 et 650 € HT. Ces ordres de grandeur permettent de comparer des devis, pas de les remplacer : le prix pertinent dépend du nombre de sites, de l'état technique de départ et du niveau de garantie souhaité. La formule de contrat de maintenance web que nous proposons précise ces points au cas par cas.

Un dernier arbitrage mérite d'être posé avec franchise : certaines entreprises préfèrent garder la main sur l'hébergement. C'est un choix légitime, à condition de nommer une personne responsable de la veille et du redémarrage des services, et de lui donner le temps de le faire. Sans cela, la réactivité attendue lors d'une alerte comme celle du 21 octobre repose sur la chance.

Plan d'action sur sept jours pour un dirigeant ou un DSI

Un plan en sept jours suffit pour passer de l'incertitude à une situation maîtrisée : inventaire le premier jour, questions à l'hébergeur le deuxième, correction ou contournement avant le cinquième, vérification des journaux et documentation avant la fin de la semaine. L'essentiel est de séparer ce qui est urgent (corriger PHP) de ce qui est important (réviser le contrat et le calendrier de fins de support).

Jour 1 : listez tous vos sites et leurs hébergements, y compris les sites secondaires, les micro-sites de campagne et les environnements de test accessibles depuis Internet. Relevez la version exacte de PHP de chacun. Jour 2 : envoyez à chaque hébergeur les quatre questions fermées citées plus haut et demandez une réponse écrite sous 48 heures. Jours 3 et 4 : pour les sites sur PHP 8.2 à 8.5 non corrigés, planifiez la mise à jour du paquet et le redémarrage ; pour les sites sur PHP 8.1 ou antérieur, décidez entre le rétroportage de l'hébergeur à titre transitoire et la montée de version, en testant d'abord sur une copie. Jour 5 : appliquez les mesures provisoires sur les sites qui ne peuvent pas être corrigés, ou mettez-les hors ligne le temps nécessaire. Jour 6 : demandez et examinez les journaux depuis le 17 octobre. Jour 7 : consignez ce qui a été fait, avec dates et interlocuteurs, et mettez à jour votre calendrier des fins de support.

Si vous n'avez pas la ressource en interne, un audit de site web couvre l'inventaire, la lecture des versions, l'examen de la configuration et un plan de remise à niveau priorisé. Ce travail d'état des lieux se fait en quelques jours et donne à votre direction une base de décision documentée. Les enjeux plus larges de sécurité de votre parc sont décrits sur notre page sécurité de site web.

Au-delà de la semaine, retenez que PHP2Shell n'est pas un accident isolé mais un symptôme : un site se dégrade quand plus personne ne regarde l'interpréteur, le CMS et l'hébergement comme un ensemble. Entre la fin de vie de PHP 8.2 au 31 décembre 2026, celle de Drupal 10 le 9 décembre et les obligations de signalement qui s'installent, la fin d'année 2026 concentre les échéances. Mieux vaut les traiter dans un calendrier unique que dans l'urgence, alerte après alerte.

Faites vérifier votre exposition avant la prochaine alerte

Si vous souhaitez savoir en quelques jours où vous en êtes, notre équipe peut dresser l'inventaire de vos sites, lire les versions de PHP, interroger vos hébergeurs et établir un plan de remise à niveau. Pour un état des lieux technique complet, découvrez notre audit de site web ; pour confier durablement la veille et les mises à jour, consultez notre contrat de maintenance web, ou contactez-nous pour une première discussion.

Questions fréquentes sur PHP2Shell et la sécurité de votre site