Cette dépêche a été rédigée avant la mise à jour prévue à 14:00 UTC le 21 octobre. PHP publiera une mise à jour de sécurité hors-cycle à 14:00 UTC le 21 octobre pour corriger deux vulnérabilités critiques que son équipe de sécurité a notées 9,2 sur l’échelle CVSS v4.0, sans en donner de description détaillée. Des chercheurs en sécurité, notamment watchTowr, indiquent que ces deux failles permettent l’exécution de code à distance (RCE). Seules les quatre branches PHP prises en charge — 8.2 à 8.5 — pourront recevoir un correctif. Aucune exploitation n’a été signalée à ce stade.
PHP2Shell : ce qu’on sait
Le signalement public de ces failles a suivi une fuite. Le 20 octobre, une publication sur un forum a affirmé que deux RCE PHP notées CVSS 10,0 et affectant les versions depuis PHP 5 seraient divulguées le 22 octobre, en ajoutant qu’elle n’avait « aucun élément au‑delà de ‹source: trust me, bro› ». watchTowr a ensuite publié sur X que l’information fuitée était réelle, que les deux failles étaient sous embargo et que plus de détails ne pouvaient être partagés pour l’instant. PHP a publié un avis le soir du 20 octobre à 19:33 UTC et a programmé la sortie pour le mercredi 21 octobre, soit un jour avant la date indiquée par watchTowr. L’avis précise que PHP pourra publier plus tôt « si les détails de l’une ou l’autre vulnérabilité deviennent publics, ou si des preuves d’exploitation active apparaissent dans la nature ».
La fuite comportait l’existence des failles, un score, une date et deux identifiants CVE ; elle ne décrivait pas le mécanisme des vulnérabilités. Le score CVSS 10,0 mentionné dans la fuite est celui de la fuite ; PHP a attribué la note 9,2 sur la version 4.0 de l’échelle. Les identifiants utilisés par des chercheurs sont CVE-2026-109618 et CVE-2026-109619, mais l’avis initial de PHP ne les nomme pas. watchTowr indique dans sa FAQ que l’étendue « n’a pas été confirmée par un avis officiel du fournisseur » et qu’aucune exigence de configuration ou d’activation de fonctionnalité n’a été décrite. Les chercheurs ont commencé à appeler l’ensemble « php2shell » ; ce nom est de leur initiative, pas celui de PHP.
Branches prises en charge et correctifs attendus
PHP corrige uniquement ses quatre branches prises en charge et consigne les modifications pour chaque branche dans son changelog. Au 24 septembre, les versions courantes et statuts de support étaient : 8.5 (8.5.11, support actif jusqu’au 31 décembre 2027), 8.4 (8.4.26, support actif jusqu’au 31 décembre 2026), 8.3 (8.3.35, correctifs de sécurité uniquement jusqu’au 31 décembre 2027) et 8.2 (8.2.34, correctifs de sécurité uniquement jusqu’au 31 décembre 2026). Plusieurs observateurs, dont certains trackers et le chercheur Kevin Beaumont, anticipent que les correctifs seront diffusés sous la forme des prochaines versions point : 8.5.12, 8.4.27, 8.3.36 et 8.2.35, mais PHP n’a pas confirmé ces numéros.
Les branches obsolètes — notamment 8.1, 8.0, 7.x et 5.x — sont hors support et ne recevront pas de correctif de la part de PHP ; si les failles affectent ces branches, les installations resteront sans correctif fournisseur.
Préparations recommandées et état des exploitations
PHP n’a publié aucun contournement. En attendant la sortie, la préparation recommandée reprend principalement les conseils d’une note de réponse rapide de Huntress, complétée par la recommandation d’isolation du CERT‑EU : inventorier chaque installation PHP, y compris PHP inclus dans des appliances fournisseurs, des logiciels Windows et des panneaux de contrôle (cPanel, Plesk) ; se tenir prêt à appliquer la mise à jour à 14:00 UTC ; patcher en priorité les systèmes exposés sur Internet ; vérifier auprès de la distribution Linux et de l’hébergeur l’éventuelle disponibilité de paquets rétroportés ; pour une branche hors support, mettre à niveau, déconnecter le système d’Internet ou le placer derrière un VPN ou un pare‑feu d’application web jusqu’à correction ; et, lorsque le patch ne peut être appliqué immédiatement, « envisager d’isoler les applications exposées sur Internet des réseaux publics jusqu’à ce qu’un correctif soit disponible », selon CERT‑EU.
Les équipes doivent aussi surveiller les processus lancés par PHP : alerter si php-fpm, php-cgi, httpd ou apache2 démarrent des shells, des interpréteurs ou des outils de téléchargement. Florian Roth propose un outil (process-watcher) qui journalise chaque programme démarré par un processus PHP avec sa ligne de commande ; cet outil voit un programme seulement après son démarrage et, selon son auteur, « n’empêche rien ». En cas de compromission présumée, isoler le serveur, préserver les journaux du serveur web et de PHP, puis rechercher des web shells, des nouveaux fichiers dans la racine web, de nouvelles tâches cron, des tâches planifiées et des comptes nouvellement créés.
À la date du 20 octobre, Huntress indiquait n’avoir observé aucune exploitation dans ses environnements partenaires, n’avoir pas construit ni reproduit de preuve de concept et ne pas connaître de code d’exploitation public. La FAQ de watchTowr liste l’exploitation comme « aucune signalée » au 21 octobre et indique que les failles ne figurent pas dans le catalogue des vulnérabilités exploitées connues (Known Exploited Vulnerabilities) de la CISA. À titre de comparaison, la divulgation de CVE-2024-4577 (une faille PHP en mode CGI sur Windows) en juin 2024 avait conduit Akamai à observer des tentatives d’exploitation contre ses honeypots dans les 24 heures.
La publication officielle de la nouvelle version devrait préciser ce qu’a volontairement passé sous silence l’avis : versions affectées, composant PHP en cause, conditions d’attaque (mode d’exécution, configuration ou authentification requise) et description technique des vulnérabilités. Au moment de la rédaction, PHP n’avait pas encore publié les correctifs.
