Salomé Sperling
Lead Creative Webdesigner
Synthèse de l'article
- PHP a publié le 21 octobre 2026 un correctif pour deux failles notées 9,2/10 (CVE-2026-109618 et CVE-2026-109619), surnommées « PHP2Shell ». Toutes les versions depuis PHP 5.4 sont touchées. Seule la mise à jour du serveur protège.
- En Belgique, le CCB a demandé de couper les sites non corrigés : police fédérale, SPF Finances, Smartschool, VRT, DPG Media ont suivi. En France, toutes les préfectures sont passées en maintenance. Aucune attaque n'était recensée en Belgique au 22 octobre.
- WordPress dépend de PHP, donc de son hébergeur. Les sites Webflow, qui ne tournent pas sur PHP, n'ont rien eu à faire. Pour un site vitrine, c'est un argument de plus pour ne plus gérer de serveur.
Résumer avec l'IA
Le 21 octobre 2026, PHP a corrigé deux failles critiques qui permettent de prendre le contrôle d'un serveur à distance, sans mot de passe. Des milliers de sites ont été coupés par précaution en Belgique et en France. Si votre site tourne sous WordPress, le mettre à jour ne suffit pas : c'est la version de PHP installée sur votre serveur qui compte.
Que s'est-il passé avec PHP le 21 octobre 2026 ?
PHP, le langage qui fait tourner environ 70 % des sites dont on connaît la technologie serveur (W3Techs), a publié en urgence les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent deux failles dans le moteur PHP lui-même, pas dans un plugin ou un thème.
La première (CVE-2026-109618) se déclenche quand une requête épuise la mémoire allouée : des données internes restent à moitié initialisées et peuvent être détournées. La seconde (CVE-2026-109619) laisse survivre un état interne après la libération de sa mémoire, qu'une requête suivante peut réutiliser. Dans les deux cas, le résultat possible est le même : un attaquant exécute son propre code sur le serveur.
Le projet PHP est clair sur les solutions de contournement : il n'en existe « no complete mitigations, updating is the only safe choice ». Autrement dit, filtrer ou bricoler la configuration ne rend pas un serveur sûr. Seule la mise à jour protège.
| Date | Événement |
|---|---|
| 2024 | Audit financé par l'État allemand (Sovereign Tech Agency, OSTIF, Quarkslab) : premiers signes du problème, sans attaque démontrée |
| 11 août 2026 | Calif démontre une exécution de code à distance, avec l'aide d'outils d'IA |
| 24 août 2026 | Wiz Research signale d'autres scénarios d'attaque |
| 20 octobre 2026 | Préavis du projet PHP. Fuite des identifiants CVE et d'une vidéo de démonstration |
| 21 octobre 2026, 5 h | Cloudflare active ses règles de protection sur son réseau |
| 21 octobre 2026, 16 h | Publication de PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Le CCB et l'ANSSI demandent de couper les sites non corrigés |
| 22 octobre 2026 | Retour progressif en ligne. Aucune attaque recensée en Belgique par le CCB |
L'intelligence artificielle a joué un rôle central. Selon Wiz, l'exploitation demandait une chaîne d'étapes à la limite de ce qu'un chercheur humain peut construire, et les modèles d'IA ont abaissé cette barrière. Le revers est évident : les attaquants ont accès aux mêmes outils.
Pourquoi tant de sites ont été coupés alors qu'aucun n'a été piraté ?
Les sites ont été coupés parce qu'une faille d'exécution de code à distance, sans authentification, est le pire scénario pour un serveur web. Personne n'a besoin de voler un mot de passe : une requête bien construite suffit.
Trois éléments ont accéléré la panique. Les détails ont fuité le 20 octobre, la veille de la publication prévue, avec une vidéo de démonstration diffusée par erreur. Amazon Web Services a signalé le 21 octobre une exploitation déjà « large » de la faille. Et Cloudflare, dont les règles de protection étaient actives dès 5 h du matin, a fait état de millions de tentatives sur son réseau.
Face à ça, les autorités ont choisi la prudence. Le Centre pour la Cybersécurité Belgique (CCB) a demandé à toute organisation incapable d'installer le correctif immédiatement de mettre son site hors ligne. En France, l'ANSSI a fait la même demande aux sites de l'État (alerte CERTFR-2026-ALE-014).
Couper n'est donc pas un aveu de piratage. Comme le résume Dimitrios Salampasis, chercheur à la Swinburne University of Technology, cité par France 24 : mettre un site hors ligne ne signifie pas qu'il a été piraté. Au 22 octobre, le CCB n'avait recensé aucune attaque contre un site belge.
Quels sites et entreprises ont été mis hors ligne ?
Les organisations mises hors ligne sont surtout des administrations, des hôpitaux et des médias : des structures qui hébergent elles-mêmes beaucoup de sites PHP et qui ne peuvent pas prendre de risque.
En Belgique
Le site du CCB lui-même a été coupé. Ont suivi la police fédérale (le 101 restant joignable), le SPF Finances (finances.belgium.be, ruling.be), les sites officiels flamands à la demande du ministre-président, le Parlement flamand, le portail du Service Public de Wallonie, des communes de Bruxelles et de Gand, des hôpitaux anversois et le Grand Hôpital de Charleroi (sans impact sur les soins), selon la RTBF et La Libre.
Côté privé, la plateforme scolaire Smartschool était inaccessible, tout comme la VRT, plusieurs sites de DPG Media et les magazines de Roularta (Le Vif, Trends Tendances, Flair, Femmes d'aujourd'hui).
Un détail résume tout l'incident : MyMinfin, l'espace fiscal en ligne, est resté accessible pendant que finances.belgium.be était coupé. La raison est simple : MyMinfin ne tourne pas sur PHP.
En France
Le ministère de l'Intérieur a placé tous ses sites exposés en maintenance préventive, y compris les préfectures et la préfecture de police de Paris, à la demande de l'ANSSI. Aucune compromission n'a été annoncée.
Ailleurs dans le monde
Aux Pays-Bas, le NCSC a coupé son propre site, tout comme Overheid.nl, MijnOverheid, DigiD et le portail du port de Rotterdam. La Finlande a restreint plusieurs services publics (Valtori), l'université de Fribourg en Allemagne a arrêté ses sites WordPress, et Wikimedia a suspendu certains services. Au Canada, des sites du gouvernement fédéral sont aussi tombés (CBC).
| Pays | Organisations hors ligne | À noter |
|---|---|---|
| Belgique (public) | CCB, police fédérale, SPF Finances, sites officiels flamands, Parlement flamand, Service Public de Wallonie, communes de Bruxelles et de Gand, hôpitaux anversois, Grand Hôpital de Charleroi | Le 101 est resté joignable. MyMinfin, qui ne tourne pas sur PHP, est resté en ligne |
| Belgique (privé) | Smartschool, VRT, DPG Media, Roularta (Le Vif, Trends Tendances, Flair, Femmes d'aujourd'hui) | Mises hors ligne préventives |
| France | Ministère de l'Intérieur, préfectures, préfecture de police de Paris | À la demande de l'ANSSI, sans compromission annoncée |
| Pays-Bas | NCSC, Overheid.nl, MijnOverheid, DigiD, portail du port de Rotterdam | Pas d'impact opérationnel pour le port |
| Finlande | Services publics de Valtori (dont le cadastre et Finna) | Accès restreint |
| Allemagne | Université de Fribourg (sites WordPress, authentification MyLogin) | Effets en cascade sur l'intranet et le webmail |
| International | Wikimedia (certains services), sites du gouvernement canadien | Suspension partielle |
Pourquoi PHP fait-il tourner autant de sites ?
PHP fait tourner autant de sites parce qu'il est le moteur des CMS les plus répandus : WordPress, mais aussi Drupal, Joomla, PrestaShop ou Magento. WordPress seul alimente plus de 40 % des sites web (W3Techs). Selon Censys, on comptait au moment de l'incident environ 2,58 millions de serveurs et 54,9 millions de sites exposés sur Internet en PHP.
Ce succès a un revers. Le langage qui fait tourner des banques, des boutiques et des services publics est maintenu par une équipe réduite. Les premiers signes de ces failles avaient été repérés en 2024 lors d'un audit financé par l'État allemand (Sovereign Tech Agency, OSTIF, Quarkslab), sans démonstration d'attaque à l'époque. Wiz compare l'ampleur de l'incident à Log4Shell, la faille Java de 2021.
Mon site WordPress est-il concerné ?
Oui, potentiellement, si votre serveur tourne sur une version de PHP antérieure à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Le point que beaucoup ratent : mettre à jour WordPress, votre thème ou vos extensions ne change rien. Automattic, l'entreprise derrière WordPress.com, l'a rappelé : ces mises à jour ne vous protègent pas à elles seules.
La question n'est donc pas « mon WordPress est-il à jour ? » mais « qui met à jour le PHP de mon serveur, et l'a-t-il fait ? ».
| Votre situation | Qui met à jour PHP | Ce que vous devez faire |
|---|---|---|
| Hébergement mutualisé | L'hébergeur | Vérifier la version dans Santé du site et demander une confirmation écrite |
| Hébergement WordPress géré | L'hébergeur, en général automatiquement | Obtenir la confirmation que la mise à jour est faite, avec la date |
| Serveur dédié ou VPS | Vous ou votre prestataire technique | Mettre à jour immédiatement et faire vérifier les journaux depuis le 20 octobre |
| Site maintenu par une agence | Selon le contrat, souvent flou | Demander par écrit qui est responsable du serveur |
| Site Webflow | Webflow (le site ne tourne pas sur PHP) | Rien sur le site. Vérifier les outils connectés hébergés ailleurs |
Ce qu'il faut faire cette semaine
- Vérifier la version de PHP : dans WordPress, menu Outils > Santé du site > onglet Infos > section Serveur.
- Si elle est inférieure aux versions corrigées, demander à votre hébergeur une confirmation écrite de la mise à jour, avec la date.
- Si vous êtes sur PHP 8.1 ou plus ancien, considérer le serveur comme exposé : le projet PHP ne publie plus de correctif officiel pour ces versions. Planifier la montée de version, en testant thème et extensions.
- Faire vérifier les journaux du serveur depuis le 20 octobre, comme le recommande le CERT-FR.
- En attendant le correctif, un pare-feu applicatif (Cloudflare, Sucuri, l'offre de votre hébergeur) réduit le risque, sans le supprimer.
Quels sont les risques permanents d'un site en PHP ?
Le vrai risque d'un site en PHP n'est pas le langage, c'est que personne n'est clairement responsable du serveur. L'hébergeur pense que c'est l'agence, l'agence pense que c'est l'hébergeur, et l'équipe marketing ne sait pas quelle version tourne.
Les chiffres de WordPress.org le montrent. Le 22 octobre 2026, 35,8 % des sites WordPress qui se connectent à ses serveurs tournaient sur PHP 8.1 ou plus ancien : des versions qui ne reçoivent plus de correctif officiel. 23,7 % de plus utilisaient PHP 8.2, dont le support de sécurité s'arrête le 31 décembre 2026. Au 1er janvier 2027, près de 6 sites WordPress sur 10 tourneront donc sur une version de PHP sans support officiel, sauf montée de version d'ici là.
À ça s'ajoute le reste de la pile : extensions pas maintenues, thèmes modifiés qu'on n'ose plus mettre à jour, accès administrateur partagés. PHP2Shell n'est pas un accident isolé. C'est la version spectaculaire d'un problème quotidien.
Pourquoi les sites Webflow n'ont-ils pas été touchés ?
Les sites Webflow n'ont pas été touchés parce que Webflow ne tourne pas sur PHP. Son Trust Center est explicite : « Webflow's core services are not built on PHP and are not affected. No action is required from customers. »
La différence est structurelle. Un site WordPress génère chaque page à la demande, sur un serveur où PHP et la base de données sont exposés à chaque visite. Un site Webflow est publié sous forme de pages prêtes à l'emploi, servies par un réseau de diffusion mondial (CDN). Le visiteur n'atteint jamais un serveur PHP que vous devriez mettre à jour. Hébergement, certificat SSL et correctifs de sécurité sont gérés par Webflow, pas par vous.
Ça ne veut pas dire zéro risque. Webflow indique évaluer encore des systèmes internes, hors production, qui utilisent PHP. Et sur votre site, ce que vous ajoutez reste sous votre responsabilité : comptes sans double authentification, scripts tiers, code personnalisé, ou outils connectés qui tournent eux-mêmes sur un serveur PHP. Un blog WordPress à côté d'un site Webflow reste un blog WordPress à surveiller.
Faut-il quitter WordPress après PHP2Shell ?
Pour un site vitrine ou de génération de leads, oui, si personne dans votre équipe ne sait quelle version de PHP tourne ni qui la met à jour. Vous payez un serveur à surveiller pour un besoin qui n'en demande pas. Webflow supprime cette question et laisse votre équipe marketing faire évoluer le site sans développeur.
Pour une boutique WooCommerce complexe ou une application métier avec une équipe technique réactive, non, pas forcément. WordPress reste un choix défendable si quelqu'un est clairement responsable du serveur, avec un processus de mise à jour testé. Changer de plateforme dans l'urgence crée d'autres risques.
Une migration bien menée ne fait pas perdre son référencement : redirections 301, conservation des URL qui rankent, reprise des balises et des données structurées. Chez We-R, une migration vers Webflow d'un site d'une vingtaine de pages avec blog prend 6 à 12 semaines. Pour comparer les deux plateformes au-delà de la sécurité, lisez notre comparatif WordPress vs Webflow.
La prochaine faille est déjà en route
PHP2Shell a été trouvée avec l'aide de l'IA, et elle ne sera pas la dernière. Les mêmes outils vont accélérer la découverte de failles dans tous les logiciels anciens et largement déployés. La question à se poser n'est plus « est-ce que mon site sera concerné ? », mais « qui s'en occupe le jour où ça arrive ? ».
Si vous n'avez pas de réponse claire, parlons-en. On fait le point sur votre site actuel et on vous dit franchement s'il faut migrer, ou pas. Découvrir notre accompagnement Webflow
Ces entreprises ont migré vers Webflow
Et leurs équipes marketing nous en remercient.
