Depuis le 21 octobre 2026, la même question remonte chez les dirigeants dont le site tourne sous WordPress, PrestaShop, Drupal ou Joomla : après la faille PHP2Shell, faut-il simplement patcher, ou en profiter pour quitter PHP ? La peur est légitime. Deux failles notées 9,2 sur 10 donnent à un inconnu le contrôle d'un serveur, sans mot de passe. Et elles touchent PHP lui-même, donc tous les sites qui en dépendent.
Mais une décision prise sous le coup de la peur coûte souvent plus cher que la faille. Cet article pose les trois réponses possibles (patcher, isoler, migrer), ce que chacune règle et ne règle pas, et l'ordre dans lequel on les enchaîne quand on veut migrer vite sans se mettre en danger.
Notre position, posée d'emblée : on patche aujourd'hui, et on décide de la migration à froid, dans les jours qui suivent. Les deux ne s'opposent pas.
Prérequis : ce qu'il faut savoir sur votre site avant de décider
- La version de PHP active (visible dans l'espace client de la plupart des hébergeurs, ou à demander à votre prestataire)
- Le type d'hébergement : mutualisé (l'hébergeur gère PHP) ou serveur dédié et VPS (c'est à vous ou à votre prestataire)
- La liste des extensions ou modules installés, et la date de leur dernière mise à jour
- Ce que le site stocke : comptes clients, commandes, données de paiement, formulaires
- Qui intervient sur le site aujourd'hui, et en combien de temps
- Le budget et le calendrier acceptables pour une refonte, même approximatifs
Ce que la faille PHP2Shell change vraiment
Les faits, d'abord. L'équipe PHP a publié le 21 octobre 2026 les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui corrigent CVE-2026-109618 et CVE-2026-109619. Toute installation PHP qui sert des pages web est concernée, quelle que soit la façon dont PHP est branché au serveur. L'avis officiel est sans ambiguïté : « There are no complete mitigations, updating is the only safe choice » (il n'existe pas de parade complète, la mise à jour est le seul choix sûr).
Deux chiffres donnent l'échelle du problème. Tenable estime entre 1,3 et 1,9 million le nombre de serveurs PHP exposés sur Internet. Et les premières attaques ont été repérées par Cloudflare à 7 h 43 UTC, alors que le correctif n'est sorti qu'à 14 h UTC : pendant un peu plus de six heures, il n'existait aucune version corrigée à installer.
Le point qui pèse le plus dans la décision concerne les anciennes versions. PHP 8.1 et les versions antérieures ne sont plus maintenues par le projet PHP. Des correctifs minimaux ont été publiés pour 7.4, 8.0 et 8.1, mais seulement sous forme de code source à compiler : sur un hébergement mutualisé, vous dépendez de votre hébergeur ou de votre distribution pour obtenir une version corrigée. Si votre site ne fonctionne qu'en PHP 7.4, vous êtes devant un vrai problème, et c'est là que la migration devient une question sérieuse.
Patcher, isoler, migrer : ce que chaque option règle
| Patcher PHP | Isoler (pare-feu, mise hors ligne) | Migrer hors de PHP | |
|---|---|---|---|
| Délai de mise en œuvre | Heures à jours | Heures | Semaines |
| Ferme la faille PHP2Shell | Oui | Partiellement, et seulement pour les attaques connues | Oui, une fois la bascule faite |
| Protège pendant la transition | Oui | Oui, au prix de la disponibilité | Non : l'ancien site reste en ligne |
| Retire une intrusion déjà en place | Non | Non | Oui, si on reconstruit à partir des contenus |
| Coût | Faible, sauf extensions incompatibles | Faible à moyen | Projet à budgéter |
| Futures urgences PHP | Toujours à gérer | Toujours à gérer | Ne vous concernent plus |
L'isolement mérite une remarque. Le CERT-FR suggère, en mesure transitoire, de bloquer au pare-feu applicatif les requêtes qui envoient des fichiers (format « multipart »). C'est efficace contre les attaques connues, mais cela casse aussi vos formulaires d'envoi de fichiers, et un attaquant patient trouvera d'autres chemins. Les mesures de configuration publiées par l'équipe PHP sont présentées par elle-même comme partielles. Isoler, c'est gagner du temps, pas se protéger durablement.
Pourquoi on ne lancerait jamais une migration à la place du correctif
Une migration, même rapide, prend des semaines. Pendant tout ce temps, l'ancien site reste en ligne, sur l'ancien serveur, avec l'ancienne version de PHP. Lancer la migration en se disant « de toute façon on change de site » sans patcher l'existant laisse la porte ouverte pendant toute la durée du projet.
L'ordre est donc toujours le même : correctif ou isolement aujourd'hui, recherche de traces d'intrusion dans la foulée, décision de migration ensuite. On peut enchaîner les trois en une semaine. On ne peut pas les inverser.
Le piège qu'on voit régulièrement : la mise à jour qui casse le site
Symptôme. L'hébergeur propose de passer de PHP 7.4 à PHP 8.2. Le gestionnaire clique, le site affiche une page blanche ou des erreurs. Il revient en 7.4 et le site refonctionne. La situation reste en l'état pendant des mois.
Diagnostic. Une extension, un thème ou un module ancien utilise des fonctions que PHP 8 a retirées. Personne ne l'a mis à jour depuis des années, parfois parce que son éditeur a disparu.
Correctif. Copier le site sur un environnement de test, passer PHP en version récente, identifier les éléments qui cassent, puis les mettre à jour ou les remplacer. Quand trop d'éléments sont abandonnés, on arrive à la conclusion qui fait mal : le site est bloqué sur une version de PHP qui ne recevra pas de correctif officiel pour PHP2Shell. C'est le cas où la migration n'est plus un confort, mais la sortie la plus réaliste.
À quoi ressemble un site sans PHP
Quitter PHP ne veut pas dire quitter les outils d'administration confortables. L'idée est de séparer ce que voient vos visiteurs de ce qu'utilisent vos équipes.
Dans un site PHP classique, chaque visiteur parle au même serveur que l'administrateur, et ce serveur a accès à la base de données. Dans une architecture découplée, la grande majorité des visites est servie par un CDN à partir de pages déjà prêtes, et l'administration vit sur une adresse distincte.
C'est l'architecture que nous utilisons pour platane.io et que nous proposons à nos clients : pages construites avec TanStack Start, contenus gérés dans Payload, diffusion par le CDN européen Bunny, hébergement chez Scaleway en France.
Aucune technologie n'est à l'abri. Ce mois-ci, nous avons nous-mêmes appliqué deux correctifs de sécurité sur cette stack (TanStack Start, puis Next.js et React). La différence ne tient pas à une technologie miracle. Elle tient à la surface exposée, plus petite, et à la discipline de mise à jour, qui fait partie de la maintenance plutôt que d'une course d'urgence.
Migrer vite sans tout casser
Une migration rapide reste une migration préparée. Les étapes qui ne se sautent pas :
- Inventaire des pages, contenus, fonctions et adresses existantes.
- Choix du périmètre : ce qui est repris tel quel, amélioré ou abandonné.
- Reprise des contenus à partir des textes et images, pas des fichiers PHP, pour ne pas embarquer une éventuelle porte dérobée.
- Redirections de chaque ancienne adresse vers la nouvelle, pour préserver le référencement.
- Bascule, puis suivi de l'indexation et du trafic pendant les semaines suivantes.
Pour une boutique PrestaShop, la reprise des produits, des clients et de l'historique de commandes ajoute une étape de vérification des données. Nous avons détaillé un cas proche dans notre article sur la migration PrestaShop.
La bonne décision cette semaine
Si votre site est sur une version maintenue de PHP, avec des extensions à jour, patcher suffit pour PHP2Shell. Profitez-en pour vérifier qu'aucune intrusion n'a eu lieu, et pour vous demander qui fera la prochaine mise à jour d'urgence.
Si votre site est bloqué sur PHP 8.1 ou antérieur, ou si chaque mise à jour devient un chantier, la faille PHP2Shell est le bon moment pour planifier une migration. À froid, après le correctif ou l'isolement, pas à la place. Si vous pensez avoir été piraté, commencez par notre guide des 48 premières heures.
L'agence Platane (https://platane.io) accompagne des TPE et PME sur le diagnostic de leur exposition à PHP2Shell et sur la migration de leur site vers une architecture sans PHP, hébergée en France. La démarche est décrite sur notre page Migration PHP.
