Mis à jour le 23 octobre 2026 · Lecture : 6 min
Le 21 octobre 2026, une grande partie du web PHP a patché en urgence. Deux failles critiques du cœur de PHP, surnommées PHP2Shell, permettaient d'exécuter du code à distance sur un serveur via une simple requête non authentifiée. Au-delà de la panique du jour, cet épisode pose une question que je vois trop rarement traitée comme elle le mérite : le choix de votre plateforme web est aussi une décision de sécurité.
Réponse express : PHP2Shell (CVE-2026-109618 et CVE-2026-109619) touche toute installation PHP servant des requêtes web et a imposé un correctif d'urgence le 21 octobre 2026. Un site hébergé comme Webflow n'expose pas votre propre serveur PHP, donc vous n'aviez rien à patcher ce jour-là. La leçon n'est pas "Webflow est invulnérable", c'est que là où vit votre site détermine qui porte la charge de sécurité.
Ce qui s'est passé, factuellement
Selon les avis publics (PHP, Help Net Security, Tenable, le centre canadien de cybersécurité, Google Cloud), PHP2Shell désigne deux failles critiques. La première exploite une corruption liée à une rupture mémoire pendant le traitement d'une requête ; la seconde, un état interne qui survit à la libération de sa mémoire et qu'une requête suivante réutilise. Dans les deux cas, « une seule requête non authentifiée peut déclencher l'attaque avant même l'exécution du code applicatif ».
Help Net Security est clair : « toute installation PHP servant des requêtes web est concernée », y compris PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed, les configurations mod_php étant les plus exposées. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, avec des correctifs rétroportés pour 7.4, 8.0 et 8.1. Et ce n'est pas théorique : Amazon a relevé via son réseau de leurres une tentative d'exploitation dès le 17 octobre, quatre jours avant la divulgation publique.
Pourquoi un site Webflow n'a pas vécu cette journée-là
Un site Webflow ne s'exécute pas sur un serveur PHP que vous administrez. Le code est compilé et servi par l'infrastructure de Webflow. Concrètement, le 21 octobre, un client sur Webflow n'avait ni serveur PHP à identifier, ni version à mettre à jour, ni fenêtre d'exposition à gérer avant le correctif. La charge était du côté de l'éditeur, pas du sien.
Je le dis sans triomphalisme, parce que ce serait malhonnête : aucune plateforme n'est à l'abri de tout. Un site Webflow reste exposé à d'autres risques (scripts tiers mal choisis, formulaires, configuration DNS, hameçonnage de vos accès). Mais sur une faille serveur PHP comme celle-ci, la surface d'attaque n'est tout simplement pas la vôtre. Pour une PME sans équipe technique d'astreinte, cette différence se mesure en nuits de sommeil.
Le vrai sujet : qui porte la charge de sécurité
Un site auto-hébergé (WordPress, PrestaShop et consorts) vous rend responsable d'une chaîne entière : la version de PHP, le serveur, les extensions, les thèmes, les mises à jour. C'est puissant et flexible, mais le jour d'une faille comme PHP2Shell, c'est à vous (ou à votre hébergeur) d'agir vite. Une plateforme hébergée déplace cette charge vers l'éditeur, au prix d'une flexibilité moindre.
Il n'y a pas de réponse universelle, il y a un arbitrage. Je le pose toujours avec mes clients à partir de leur réalité : avez-vous une équipe technique ? Des besoins fonctionnels que seul un CMS ouvert couvre ? Une tolérance au risque opérationnel ? J'ai détaillé ce comparatif dans Webflow vs WordPress en 2026. Et si votre site a été généré à la va-vite, lisez mon audit des sites générés par IA : la dette de sécurité y est souvent invisible.
Que faire, selon votre situation
- Vous êtes sur un site PHP (WordPress, Presta…) : vérifiez auprès de votre hébergeur que les versions corrigées sont appliquées, et planifiez une migration si vous êtes en PHP 8.1 ou antérieur, qui n'est plus supporté.
- Vous êtes sur Webflow : rien à patcher sur cette faille, mais profitez-en pour auditer vos scripts tiers et vos accès.
- Vous hésitez sur une refonte : intégrez la question de sécurité et de maintenance au choix de plateforme, pas seulement le design et le prix.
Un dernier point que je retiens de cet épisode : la rapidité compte autant que la correction. L'exploitation a été détectée quatre jours avant la divulgation publique, et le NCSC britannique a même conseillé de mettre hors ligne les systèmes impossibles à corriger immédiatement. Cloudflare a de son côté publié des règles de pare-feu applicatif pour les vecteurs connus, y compris sur son offre gratuite. Tout cela demande, chez un site auto-hébergé, quelqu'un qui surveille, décide et agit dans la journée. Si vous n'avez pas cette personne en interne ou chez un prestataire, l'auto-hébergement n'est pas un choix neutre : c'est un risque que vous portez sans forcément le savoir.
Ce qu'un correctif ne règle pas
Patcher une faille vous remet à zéro, ça ne construit pas un site rapide, bien structuré et visible. Le choix de plateforme, l'architecture, la performance (qui pèse sur le SEO et l'expérience) et la maintenance dans la durée sont des décisions de fond. C'est ce que je prends en charge en création de site web, avec le SEO intégré dès la conception plutôt que recollé après coup. Sur la performance, voir aussi Core Web Vitals (INP, LCP, CLS).
Vous vous demandez si votre plateforme actuelle est le bon choix pour les trois prochaines années ? Réservez 30 minutes, on fait le point sans jargon.
Sources
- Help Net Security, PHP2Shell (21 octobre 2026)
- Tenable, FAQ CVE-2026-109618 / 109619
- Korben, failles critiques PHP (21 octobre 2026)
Les liens de cet article
- 🔗 Interne : Création de site web, SEO
- 🔗 Interne : Webflow vs WordPress 2026, Audit site généré par IA, Core Web Vitals
- 🌐 Externe : Help Net Security, Tenable
L'auteur : Charles-Henry Soulet, fondateur de Treelink. Je conçois des sites pensés pour durer : performants, bien structurés et visibles, avec le bon arbitrage de plateforme.