Le 21 octobre, le centre national néerlandais de cybersécurité a mis son propre site web hors ligne. Non pas parce que WordPress avait été piraté, mais parce que l'interpréteur PHP qui le sous-tend aurait pu l'être.
Ce jour-là, le projet PHP a livré les correctifs pour deux bugs d'exécution de code à distance non authentifiés dans l'interpréteur lui-même, CVE-2026-109618 et CVE-2026-109619. Tout site où PHP répondait aux demandes publiques devait être corrigé ou être mis hors ligne. Les sites servant du HTML statique depuis un CDN n'avaient pas de processus PHP dans le chemin de la requête, donc il n'y avait rien à corriger à la périphérie. WordPress Headless avait toujours besoin que son backend soit mis à jour, mais le site public restait opérationnel. Ci-dessous : la chronologie, l'argument architectural, un tableau de décision par stack, un plan 30/60/90 jours, et une checklist si vous restez sur PHP pour l'instant.
Si vous exécutez PHP, faites ceci aujourd'hui.
- Confirmez que la version en cours d'exécution est 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou un backport du vendeur dont vous avez lu l'avis, et redémarrez chaque worker.
- Vérifiez ce que votre panneau de contrôle d'hébergement a réellement expédié, pas ce que le tableau de bord dit.
- Traitez les atténuations ini de PHP et toute règle WAF comme un pont vers le correctif, pas comme un substitut.
- Sur 7.4 à 8.1, demandez à votre hébergeur s'il a construit les backports source de l'équipe de sécurité, et réservez la mise à niveau de toute façon.
Ce qui s'est passé le 21 octobre 2026
La chronologie importe car elle explique la panique. Selon Tenable, les identifiants CVE ont circulé sur Hacker News et les réseaux sociaux le 20 octobre. Plus tard ce jour-là, l'équipe de sécurité de PHP a publié un avis préalable d'une publication pour le 21 octobre à 14:00 UTC, en disant qu'elle pourrait arriver plus tôt si les détails devenaient publics. Tenable rapporte aussi, citant watchTowr, que la divulgation était à l'origine prévue pour le 22 octobre sous embargo.
L'équipe de sécurité de PHP a ensuite publié son avis le 21 octobre, intitulé « Avis de sécurité: vulnérabilités critiques d'exécution de code à distance, mettez à jour maintenant » (archives des actualités php.net). La déclaration conjointe d'ENISA place les mises à jour à 13:40 UTC. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
Les deux bugs, d'après les avis GitHub:
- CVE-2026-109618: exécution de code à distance via corruption de mémoire insuffisante.
- CVE-2026-109619: exécution de code à distance via état global obsolète, une utilisation après libération entre requêtes traitées par le même worker.
L'équipe de sécurité de PHP évalue les deux à CVSS v4.0 9.2. Tenable note que certains premiers rapports, y compris watchTowr et un post Hacker News, ont dit 10.0. Chaque SAPI de service web est concernée: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed. L'avis OOM désigne mod_php comme le plus exposé, car l'échec se produit entièrement avant l'exécution de tout code applicatif. Calif dit que le chemin de code le plus ancien affecté remonte à PHP 5.4.0. La découverte est créditée à Wiz, Calif et OpenAI, avec recherche assistée par l'IA.
Puis les pannes. Reuters et RTE ont rapporté des services gouvernementaux mis hors ligne aux Pays-Bas, en Finlande, en France et en Australie, y compris le site du centre néerlandais de cybersécurité national lui-même. CERT-EU a recommandé d'isoler les applications accessibles par Internet jusqu'à correction, et CISA a exhorté à appliquer immédiatement les correctifs. Krebs rapporte que Cloudflare a déployé des règles WAF à 3:02 UTC. Amazon Threat Intelligence dit avoir vu une tentative le 17 octobre et a ensuite décrit l'exploitation comme généralisée.
Sur l'exploitation, les sources divergent, et vous devez le savoir. La PHP Foundation a dit qu'elle n'avait pas identifié d'exploits fonctionnels au moment de la publication. Krebs rapporte des experts disant que des exploits fonctionnels existent. Tenable a dit que du code prétendant exploiter les bugs circulait mais qu'elle n'en avait vérifié aucun.
Pourquoi le conseil était de corriger maintenant ou d'aller hors ligne
L'exécution de code à distance non authentifiée dans le chemin de requête signifie que le serveur web est la cible. Il n'y a pas de connexion pour la mettre devant, pas de plugin pour la désactiver. Une requête arrive, PHP l'analyse, et le bug est déjà en jeu. L'avis OOM confirme l'impact comme exécution de code non authentifiée en tant que compte de worker web, validée sur HTTP contre mod_php avec des limites par défaut d'entrée et de mémoire.
Les atténuations que PHP a énumérées sont réelles, et ce sont des solutions d'urgence. Les avis disent:
- Définissez
memory_limit=-1administrativement (viaphp_admin_value), gardezpost_max_sizeconservateur, et bloquez les requêtes multipart à la façade si vous ne les utilisez pas. - Définissez
session.upload_progress.enabled=0. - Sur PHP 8.5, définissez
fatal_error_backtraces=0. - Redémarrez chaque worker après l'un de ceux-ci.
Les mêmes avis sont catégoriques : la mise à jour est le seul correctif complet. Pour le bug d'état obsolète, il n'existe aucune atténuation de configuration générique complète. Gina Peter Banyard, développeur du noyau PHP, citée par Tenable, a déclaré que la seule atténuation est de corriger ou de mettre à niveau PHP, et Joe Ferguson, responsable de la version PHP 8.6, a déclaré que les paramètres ini ne vous sauveront pas. Traitez donc la liste comme un pont pour un après-midi, non comme une posture.
Deux problèmes pratiques ont rendu la journée plus difficile qu'une simple mise à jour de version. L'hébergement partagé et les panneaux de contrôle livrent les paquets PHP selon leur propre calendrier, de sorte que la version que vous pensez utiliser n'est peut-être pas celle qui s'exécute. Plesk a publié son propre avis pour le PHP qu'il livre, ce qui est le type de page que vous devez consulter plutôt que de supposer.
Et puis les anciennes branches. L'avis de sécurité de php.net indique que PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet et renvoie aux distributions et aux fournisseurs LTS pour les rétroportages. L'équipe de sécurité a publié des branches de rétroportage source minimalistes pour 7.4, 8.0 et 8.1 sur GitHub, mais un correctif source n'est pas une version: quelqu'un doit quand même le compiler et le livrer à votre hébergeur. PHP 5.4 à 7.3 n'en reçoivent aucun. Si vous n'aviez jamais effectué la mise à niveau, c'était le 21 octobre pour vous.
Quelques chiffres sur l'échelle. W3Techs montre PHP sur 69,3 % des sites web avec un langage côté serveur connu au 22 octobre, avec 65,3 % de ceux-ci sur la version 8, 26,9 % sur la version 7 et 7,7 % sur la version 5. Censys compte 2,58 millions d'hôtes exposés à Internet et 54,9 millions de propriétés web exécutant PHP. C'est beaucoup de workers à redémarrer.
Qui n'avait rien à faire le 21 octobre
Voici l'exposition en termes de chemin de requête. Posez une question à n'importe quel site : quand un visiteur charge une page, quel code s'exécute pour lui répondre ?
HTML statique sur un CDN
Si la réponse est « rien, le CDN retourne un fichier », PHP2Shell ne touche pas au site public. Aucun processus PHP ne répond aux requêtes, il n'y a donc rien à corriger à la périphérie et aucune raison de mettre hors ligne quoi que ce soit. J'exécute gautamkhorana.com sur Astro avec une sortie statique. HostList, que j'ai construit sur Next.js et Supabase avec environ 28 000 pages programmatiques, n'avait aucun processus PHP à corriger. Deluxe Astrology non plus, qui exécute 91 000+ pages en 30 langues. Personne n'a reçu d'appel le 21 octobre.
Headless WordPress
Headless est une autre histoire, et je préfère être précis que flatteur. Le backend PHP avait toujours besoin de 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ce jour-là, car WordPress s'exécute toujours sur PHP. La différence est l'endroit où il se trouve. Derrière un pare-feu ou une liste blanche d'adresses IP, avec le site public servi par Astro ou Next.js, le backend n'était pas dans le chemin de la requête d'un visiteur. Le correctif était une tâche de maintenance, non une panne publique.
Disons-le clairement : ce n'est pas « headless est inviolable ». Un attaquant qui peut atteindre le backend peut toujours atteindre le bug, c'est pourquoi la liste blanche importe. Les frameworks SSR portent leurs propres risques d'exécution serveur, couverts dans l'article sur la sécurité Next.js, Astro et Nuxt, et la comparaison plus large se trouve dans la sécurité headless vs WordPress. Je ne vais pas répéter l'un ou l'autre ici.
Un schéma, pas un cas isolé
Ce n'était pas la première fois que le chemin de requête de PHP faisait la une. L'injection d'arguments PHP-CGI, CVE-2024-4577, est arrivée en 2024. Il y avait un bug PHP-CGI plus ancien en 2012. Maintenant PHP2Shell. Des failles différentes, même forme : le code qui se tient devant chaque requête publique est touché, et tout le monde en aval s'agite.
Maintenant la leçon qui coupe l'autre sens. React2Shell sur Next.js a montré que les runtimes SSR portent leur propre exposition au chemin de requête. Si un serveur JavaScript répond à chaque requête de page, c'est le nouveau PHP pour les fins de correction. Le passage de WordPress à un site rendu côté serveur Next.js déplace la surface d'attaque. Cela ne le supprime pas. La sortie statique est l'affirmation forte ; SSR est un compromis.
La question n'a donc jamais été « quel langage ». C'est « quel code répond à une requête publique ». Réduisez cette liste et vos jours d'incident seront plus courts quelle que soit la prochaine CVE écrite dans le langage.
Il y a aussi un point tourné vers l'avenir. Les chercheurs de Wiz ont écrit que les failles étaient présentes depuis des décennies, que leur exploitation prenait une chaîne d'étapes « à la limite de ce que les chercheurs humains pouvaient pratiquement réaliser », et que « les modèles d'IA frontière ont substantiellement réduit cette barrière » (Krebs). L'implication, qui est la mienne plutôt que la leur : si les anciennes failles deviennent moins chères à transformer en exploits, la cadence de divulgation augmente pour chaque runtime. Prévoyez plus de jours comme celui-ci, pas moins.
Ce que le 21 octobre vous a coûté, par pile
| Pile | PHP dans le chemin de requête publique ? | Ce que vous deviez faire le 21 octobre | Ce que vous coûte le prochain CVE PHP | Un chemin de migration sensé |
|---|---|---|---|---|
| WordPress classique ou autre CMS PHP | Oui, chaque page | Mettez à jour PHP vers une version corrigée, redémarrez chaque worker, ou isolez le site jusqu'à ce que vous puissiez le faire | La même ruée, sur le site public | Passez au headless, type de page après type de page |
| Headless WordPress (backend PHP derrière un pare-feu, frontend Next.js ou Astro) | Non, backend seulement | Patchez le PHP backend ; le site public a continué à être servi | Une fenêtre de patch sur un hôte verrouillé, sans interruption publique | Restez ; gardez le backend autorisé |
| Laravel ou une app PHP personnalisée | Oui | Mettez à jour le runtime, redémarrez les workers, vérifiez ce que votre hôte a fourni | La même ruée | Mettez un frontend statique ou SSR devant et déplacez les types de pages graduellement |
| Jamstack statique (Astro, Next.js static export, Nuxt generate, Eleventy) | Non | Rien à la périphérie ; vérifiez les outils de build et toute origine | Rien à la périphérie | Restez |
| Next.js ou Nuxt avec SSR | Pas de PHP, mais un serveur JavaScript répond aux requêtes | Rien pour PHP ; ses propres avis de runtime s'appliquent | Un CVE de runtime différent avec la même forme | Déplacez les pages qui n'ont pas besoin de rendu par requête vers une sortie statique |
WordPress classique ou autre CMS PHP. Drupal, Magento, Joomla et WordPress s'exécutent tous sur PHP, et Calif rapporte confirmer l'exécution de code distant sans authentification préalable contre des versions spécifiques des quatre, selon la FAQ de Tenable. Cette ligne a supporté tout le coût de la journée.
WordPress Headless. Vous avez appliqué le correctif, mais selon votre calendrier et derrière un pare-feu. Les éditeurs ont continué à éditer. Les visiteurs n'ont rien vu.
Laravel ou PHP personnalisé. Même exposition que le CMS classique, avec une subtilité : personne ne publie un avis produit pour votre application personnalisée, donc vous gérez l'inventaire. Le référentiel php2shell de NCSC-NL indique que les applications PHP personnalisées ne sont pas enregistrées dans son aperçu.
Jamstack statique. Rien à faire à la limite. Si votre build s'exécute sur une boîte CI, appliquez le correctif quand c'est pratique, car elle ne sert pas les visiteurs.
SSR avec Next.js ou Nuxt. Pas de PHP, pas de PHP2Shell. Mais un processus serveur répond toujours aux demandes, et React2Shell rappelle que ce processus a ses propres mauvais jours.
Le plan 30/60/90 jours
L'objectif est de retirer la surface publique de PHP sans reconstruire l'expérience d'édition.
- D'ici le jour 30 : listez vos types de pages (articles, pages de destination, pages produit, archives) et marquez lesquels nécessitent vraiment une logique par demande. Confirmez la version PHP sur chaque hôte. Mettez un CDN devant l'origine et restreignez l'admin à une liste blanche.
- D'ici le jour 60 : déployez un front-end Astro ou Next.js pour le un ou deux types de pages statiques avec le plus de trafic, construits à partir de l'API de contenu WordPress. Déclenchez une reconstruction à la publication. Ajoutez des redirections 301 pour chaque URL que vous déplacez.
- D'ici le jour 90 : migrez les types de pages restants qui peuvent être statiques. Fermez l'origine PHP au trafic public afin que seul le processus de build et vos éditeurs autorisés y accèdent. Tout ce qui nécessite vraiment un serveur (recherche, formulaires, comptes) va à un petit service nommé que vous pouvez corriger indépendamment.
Retirer la surface publique de PHP sans perdre le CMS
Vous n'êtes pas obligé de jeter WordPress pour retirer PHP du chemin de demande. WordPress Headless garde les éditeurs, le contenu et le flux de travail des plugins pour l'écriture et les approbations, tandis qu'Astro ou Next.js sert le site. Les éditeurs gardent l'écran qu'ils connaissent. Les visiteurs reçoivent des fichiers d'un CDN.
Migrez progressivement. Choisissez un type de page, reconstruisez-le sur le nouveau front-end, redirigez 301 les anciennes URL, et passez à autre chose. L'admin reste en PHP, derrière une liste blanche. Le motif d'hébergement est simple : origine verrouillée, CDN devant, build à la publication.
Sur le choix du framework : Astro pour les sites de contenu, Next.js quand le site a besoin d'une couche application, Nuxt pour les équipes Vue. Les compromis plus profonds sont dans la comparaison des générateurs de sites statiques et le guide WordPress Headless.
Sur l'effort, en utilisant uniquement les tarifs de départ : la migration de WordPress à Astro coûte à partir de 7 k$, le développement WordPress Headless à partir de 10 k$, et une migration CMS hérité à partir de 5 k$. Si le site a besoin d'une couche application, la migration de WordPress à Next.js à partir de 10 k$ est la route qui convient. Ce sont des points de départ, et le chiffre réel dépend des types de pages, des intégrations et de la part du flux de travail d'édition que vous souhaitez préserver. Si vous envisagez de quitter PHP entièrement, la page quitter WordPress couvre ce chemin.
Le jour le moins cher pour commencer n'est pas le jour après un avis. Mais le jour après un avis est quand les budgets sont approuvés, alors utilisez-le.
Si vous restez sur PHP pour le moment
Certains sites resteront en place pendant un an ou trois. D'accord. Faites ceci en attendant :
- Confirmez que la version PHP en cours d'exécution est 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou un backport du fournisseur dont vous avez lu l'avis), et que chaque worker a redémarré. Une mise à niveau de paquet qui laisse tourner d'anciens workers n'a rien corrigé.
- Vérifiez ce que votre panneau de contrôle d'hébergement a réellement livré, plutôt que ce que le tableau de bord indique.
- Appliquez les atténuations répertoriées de PHP uniquement comme pont. Les avis indiquent qu'elles ne sécurisent pas une installation, et l'avis OOM met en garde contre
RLIMIT_ASetRLIMIT_DATA, qui déclenchent le chemin vulnérable. - Planifiez dès maintenant la sortie de 7.4 vers 8.1. Le projet PHP ne met plus à jour 8.1 et les versions antérieures, et vous dépendez du backport de quelqu'un d'autre.
- Placez le site derrière un WAF en attendant de patcher. Le CTO de Cloudflare, Dane Knecht, a appelé ses règles « un PALLIATIF uniquement », et Tenable note qu'elles couvrent seulement le trafic routé par Cloudflare.
- Guettez les shells web et les fichiers PHP qui ne devraient pas exister. Wiz s'attend à une exploitation massive pour les installer, alors vérifiez les répertoires de téléchargement et les fichiers récemment modifiés.
Pour les sites qui resteront sur WordPress, le service de sécurité WordPress à partir de 150 $/mois couvre le patching continu et la surveillance.
Le fait le plus frappant du 21 octobre est que le bug vivait dans le seul endroit que chaque visiteur PHP touche, donc les seuls sites n'ayant rien à faire étaient ceux où PHP ne répondait jamais à une demande publique. La sortie statique est la version forte de cette affirmation ; un WordPress headless avait toujours besoin que son backend soit patché, et SSR échange simplement un runtime pour un autre.
FAQ
WordPress est-il affecté par PHP2Shell ?
WordPress lui-même n'est pas le bogue. Les failles se trouvent dans PHP, et WordPress s'exécute sur PHP, donc tout site WordPress sur un PHP non corrigé était exposé. La FAQ de Tenable, citant Calif, rapporte l'exécution de code distant sans authentification préalable confirmée contre des versions WordPress spécifiques, ce qui règle la question.
Un WordPress headless a-t-il encore besoin du patch ?
Oui. Le backend s'exécute sur PHP, et un attaquant qui peut l'atteindre peut atteindre le bug. Ce que headless change, c'est l'exposition : le backend peut se situer derrière un pare-feu ou une liste d'autorisation tandis qu'un front end séparé sert le public.
Un site Next.js ou Astro est-il plus sûr que PHP ?
La sortie statique de l'un ou l'autre est plus sûre contre cette classe de bug, car aucun runtime côté serveur ne répond aux demandes. SSR est un compromis : vous échangez PHP pour un runtime serveur JavaScript avec ses propres avis, comme React2Shell l'a montré.
Un WAF me protège-t-il ?
Partiellement, et seulement pendant un certain temps. Cloudflare a appelé ses règles un palliatif et elles ne couvrent que le trafic par Cloudflare. Un WAF vous gagne du temps pour patcher. Ce n'est pas un patch.
Dois-je mettre mon site hors ligne ?
CERT-EU a recommandé d'envisager l'isolation des applications accessibles sur internet jusqu'à ce qu'un correctif soit disponible, et la déclaration conjointe d'ENISA dit la même chose lorsque la correction immédiate n'est pas possible. Si vous pouvez patcher rapidement, patchez. Si vous ne pouvez pas, l'isolation est un choix raisonnable.
Quelles versions PHP sont corrigées ?
PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, selon les avis PHP.
PHP 7.4, 8.0 et 8.1 sont-ils patchés ?
Pas avec des versions. L'avis de sécurité de php.net indique que 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet PHP, et l'équipe de sécurité a publié des branches de rétroportage source minimalistes pour 7.4, 8.0 et 8.1 à la place. Demandez à votre hébergeur ou à votre distribution si elle les a compilées; de toute façon, planifiez la mise à niveau.