Le 21 octobre 2026 à 14:00 UTC, PHP publie les correctifs de PHP2Shell, deux failles d’exécution de code à distance notées 9,2/10. Le 22 octobre au matin, synaltic.fr tourne sur PHP 8.3.36 corrigé, via l’image officielle wordpress:7.1.3-php8.3-apache et un helm upgrade. Entre les deux : PHP, les CMS, Docker, Helm et nous. Personne n’a attendu personne.
Chronologie : de la découverte à notre helm upgrade
Deux mois de travail coordonné sous embargo, puis moins de 24 heures entre la publication du correctif et notre site à jour. Heures en UTC sauf mention contraire.
| Quand | Qui | Quoi |
|---|---|---|
| 19 août 2026 | Wiz Research | Découverte de la première faille, avec des outils d’IA (Wiz Atlas, Gemini, GPT). RCE confirmée sur Drupal le 20, sur WordPress le 21 août. |
| 24 août | Wiz → PHP | Signalement à l’équipe sécurité PHP. |
| 21 septembre | PHP | Accusé de réception, début du correctif coordonné : distributions Linux et vendeurs LTS reçoivent les patches en avance ; Google Cloud, Cloudflare, AWS, Microsoft, Automattic, Fastly, Akamai préparent leurs mitigations. |
| 17 octobre | Un attaquant | Première tentative d’exploitation vue par le honeypot MadPot d’Amazon, 4 jours avant la publication. |
| 20 octobre | Fuite | Les identifiants CVE circulent sur Hacker News et les réseaux sociaux. PHP publie un préavis et avance la publication du 22 au 21. CERT-EU publie l’avis 2026-018. |
| 20 oct. 22:21 PT | Palo Alto | Signature de détection (Threat ID 543004) avant même le correctif PHP. |
| 21 oct. matin | Pays-Bas, Japon | DigiD, MijnOverheid, Sakura, BASE, Xserver mettent des services hors ligne par précaution. |
| 21 oct. 07:34 | Hébergeurs → Patchstack | Premiers incidents d’exploitation active signalés. |
| 21 oct. 07:43 | Cloudflare | Règles WAF déployées pour tous les clients, plan gratuit compris. |
| 21 oct. 14:00 | PHP | Publication de PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 + backports source pour 7.4, 8.0, 8.1. |
| 21 oct. après-midi | docker-library/php | PR #1694 fusionnée : les quatre versions corrigées dans les définitions d’images. |
| 21 oct. ~15:40 | Docker Hub | Les tags apparaissent… sans image derrière (« deployment issue » reconnue par un mainteneur, issue #1700). |
| 21 oct. soir | Synaltic | blog-synaltic éteint par précaution. |
| 21 oct. ~22:00 | Docker Hub | Images Debian réelles publiées (php:8.3-apache, php:8.4-fpm…). Alpine dans la nuit. |
| Nuit du 21 au 22 | docker-library | Images officielles Drupal, Joomla, puis WordPress reconstruites sur les bases corrigées. |
| 21–22 oct. | Debian, Ubuntu, Alpine 3.24 | Paquets corrigés publiés. RHEL, Amazon Linux, SUSE : pas encore au moment du rapport Fortinet. |
| 22 oct. matin (Paris) | Synaltic | Sauvegarde Velero + mysqldump, bascule sur wordpress:7.1.3-php8.3-apache (PHP 8.3.36), mise à jour des extensions par wp-cli, helm upgrade, commit. Site vérifié. |
| 22 oct. | Palo Alto, Cisco, Fortinet | Toujours sans version corrigée (voir plus bas). |
Délai entre le correctif PHP et notre site corrigé : moins d’une journée de travail, dont l’essentiel passé à attendre que Docker Hub publie les vraies images.
La chaîne, maillon par maillon
Chaque maillon a fait sa part sans attendre d’ordre de l’autre : c’est ce qui rend la chaîne rapide. Aucun n’a eu besoin de négocier une licence, un ticket support ou une fenêtre de maintenance avec le maillon d’avant.
| Maillon | Ce qu’il a fait | Délai après le correctif PHP |
|---|---|---|
| Communauté PHP | Correctif coordonné pendant 2 mois avec les distributions et les hyperscalers ; quatre branches supportées corrigées le même jour ; backports source offerts pour trois branches en fin de vie (7.4, 8.0, 8.1) ; publication avancée de 24 h après la fuite. | 0 h (c’est lui le correctif) |
| WordPress, Drupal, Joomla, Magento | Rien à corriger dans leur code : la faille est dans l’interpréteur. Leur travail a été de le dire vite et clairement (Patchstack, communautés Magento) et de reconstruire leurs images officielles. Le plugin WordPress « The SEO Framework » a préféré couper ses serveurs plutôt que d’attendre. | Quelques heures (images) |
| Distributions Linux | Debian, Ubuntu, Alpine : paquets publiés le jour même grâce à l’accès anticipé (liste distros). | 0 à 24 h |
| Docker (docker-library) | PR fusionnée l’après-midi, images php publiées dans la soirée, puis Drupal, Joomla, WordPress reconstruits dans la nuit. Tout le processus est public : une PR, une issue, des mainteneurs qui s’excusent d’un retard de 6 h. | ~8 h (php), ~16 h (wordpress) |
| Helm | Aucune dépendance à un éditeur : notre chart référence un tag d’image. Changer wordpress:6.4.3-apache en wordpress:7.1.3-php8.3-apache, helm upgrade, et Kubernetes fait le reste. L’historique Helm et Velero donnent le retour arrière. | Le temps d’un commit |
| Synaltic | Site éteint le 21 au soir, redémarré directement sur l’image corrigée le 22 au matin, extensions et thème mis à jour par wp-cli, chart aligné, vérifications (php -v, logs, helm history). Aucun fichier modifié à la main. | < 1 journée de travail |
Le point commun : à chaque étage, la source est publique et le correctif est un artefact que n’importe qui peut reconstruire. Quand Docker Hub a eu son incident de déploiement, la PR était déjà fusionnée ; un docker build local aurait suffi pour ne pas attendre.
Et le propriétaire ? La même faille, pas la même vitesse
Le meilleur comparatif n’est pas un autre incident : c’est PHP2Shell lui-même. Des éditeurs propriétaires embarquent PHP dans leurs produits. Au 22 octobre, quand notre site était déjà corrigé, voici où ils en étaient.
| Éditeur | Produits concernés | État au 22 octobre | Ce que le client peut faire |
|---|---|---|---|
| Palo Alto Networks | Toutes les versions de PAN-OS et Panorama | Aucune version corrigée, aucune date annoncée | Restreindre l’interface d’administration, compter sur les signatures IPS |
| Fortinet (FG-IR-26-186) | 12 produits « en cours d’investigation » (FortiADC, FortiSIEM, FortiSOAR, FortiClient EMS…) | Ni version corrigée ni contournement pour les produits en revue | Attendre, isoler |
| Cisco (cisco-sa-php-october26) | 18 produits et 13 services cloud en cours d’investigation (ISE, Catalyst Center, SD-WAN Manager, Webex, Umbrella…) | Aucune version corrigée, aucun contournement | Attendre un Bug ID |
Ces éditeurs ont la même information que nous, au même moment, et probablement plus tôt. Ce qui les ralentit, ce n’est pas la compétence : c’est que le client ne peut pas reconstruire le produit lui-même. Il ne peut ni changer un tag d’image, ni appliquer le backport, ni même savoir quelle version de PHP tourne dans sa boîte. Il attend.
Ce n’est pas propre à PHP2Shell. Il a fallu un mois à la communauté PHP pour livrer un correctif. Quelques précédents récents, côté propriétaire :
| Incident | Exploitation observée | Correctif complet | Délai |
|---|---|---|---|
| Microsoft SharePoint on-prem « ToolShell » (CVE-2025-53770), 2025 | Faille démontrée à Pwn2Own en mai 2025, premier patch en juillet 2025 contourné, exploitation massive à partir du 18 juillet | Correctifs d’urgence les 19–21 juillet ; SharePoint Online (le SaaS de Microsoft) protégé avant les clients on-prem | ~2 mois depuis la démonstration |
| Oracle E-Business Suite (CVE-2025-61882), 2025 | Exploitation par Cl0p dès août | Patch d’urgence le 4 octobre | ~2 mois |
| Ivanti Connect Secure (CVE-2025-0282), 2025 | Exploitation dès mi-décembre 2024 | ICS corrigé le 8 janvier, Policy Secure et ZTA le 21 janvier | 3 à 5 semaines |
Dans chaque cas, le client ne pouvait rien faire d’autre qu’attendre l’éditeur, ou débrancher. Avec PHP2Shell, c’est exactement la situation des clients PAN-OS aujourd’hui.
L’open source n’est pas magique pour autant : Log4Shell (2021) a eu son correctif en quelques heures, mais il a fallu trois versions (2.15, 2.16, 2.17) pour clore le sujet. La différence n’est pas qu’il n’y a jamais de raté, c’est que le raté est visible et que n’importe qui peut le corriger.
Ce qui a grincé
Un article qui ne dit que du bien n’est pas crédible. Quatre choses n’ont pas marché comme prévu, et toutes ont été traitées au grand jour.
- L’embargo a fuité. Les CVE ont circulé le 20 octobre, un attaquant testait déjà un honeypot d’Amazon le 17. La réponse : PHP a avancé la publication de 24 h au lieu de nier.
- Docker Hub a publié des tags vides pendant ~6 h. Les tags 8.3.36 et consorts existaient sans image derrière. Un mainteneur l’a écrit dans l’issue #1700 ; les images sont arrivées dans la soirée. Entre-temps, la PR fusionnée permettait de reconstruire soi-même.
- Le dépôt Remi n’avait rien le jour J. C’est un dépôt bénévole ; Patchstack a recommandé de passer aux paquets de la distribution ou de compiler. Le bénévolat a ses limites, et l’écosystème l’a dit sans détour.
- PHP 8.1 et antérieurs ne sont plus supportés. Les backports source existent pour 7.4, 8.0 et 8.1, mais pas de binaires officiels. Qui tourne encore en PHP 7 dépend de son distributeur ou de lui-même. Chez nous, l’image wordpress:6.4.3-apache embarquait PHP 8.2.17, encore supporté : nous avions de la marge, mais moins que nous ne le pensions.
Pourquoi la chaîne tient
La vitesse ne vient pas d’un héros, mais de trois propriétés de la chaîne.
- Chaque maillon publie un artefact reconstructible. Un tarball PHP, un Dockerfile, un chart Helm. Si le maillon d’au-dessus est en retard, le maillon d’en dessous n’est pas bloqué : il reconstruit.
- La coordination se fait en public, avec un embargo court. Deux mois de préparation avec les distributions et les hyperscalers, puis tout le monde publie le même jour. Quand l’embargo a fuité, la publication a été avancée, pas reportée.
- Le client est opérateur, pas spectateur. Notre collègue n’a eu besoin de l’accord de personne pour changer un tag d’image, et il avait son plan de retour arrière (Velero, mysqldump, historique Helm) avant de toucher quoi que ce soit.
C’est l’argument que nous portons chez nos clients sous le nom de souveraineté : ce n’est pas une question de drapeau, c’est la capacité à corriger soi-même, le jour même, sans demander la permission.
Sources
- Wiz Research — PHP2Shell: AI uncovers critical RCE vulnerabilities — découverte, chronologie août–octobre, analyse technique
- Patchstack — PHP major vulnerability alert (10-2026) — chronologie du 21 octobre heure par heure, côté WordPress
- Help Net Security — PHP2Shell patched, update now — versions corrigées, honeypot Amazon, distributions, dépôt Remi
- Help Net Security — What PHP2Shell means for Fortinet, Cisco and Palo Alto customers — état des éditeurs au 22 octobre
- Palo Alto Networks — CVE-2026-109618 advisory
- Tenable — php2shell FAQ — fuite du 20 octobre, publication avancée, CERT-EU 2026-018
- watchTowr — PHP2Shell FAQ — exploitation observée sur honeypots
- IT-Connect — PHP2Shell and Docker — PR #1694, tags vides, reconstruction des images Drupal/Joomla/WordPress
- Ceymox — Adobe Commerce et PHP2Shell — situation Magento / Adobe Commerce
Sections commentaires non disponible.