PHP : deux failles critiques corrigées ce 21 octobre, prépare tes serveurs

Le 20 octobre 2026, l'équipe de sécurité de PHP a prévenu qu'elle publierait le mercredi 21 octobre à 14 h UTC, soit 16 h à Paris, une mise à jour corrigeant deux vulnérabilités critiques, notées chacune 9,2 sur 10 (CVSS v4.0). Le détail des failles, les versions touchées et les versions corrigées ne seront dévoilés qu'avec les correctifs. La consigne est claire : tout le monde doit se tenir prêt.

Ce que l'équipe PHP a annoncé

L'annonce tient en quelques lignes : deux vulnérabilités critiques, un rendez-vous précis et une consigne, se préparer dès maintenant pour mettre à jour dès que les nouvelles versions seront disponibles. L'équipe se réserve le droit de publier plus tôt si le détail d'une des failles devient public ou si une exploitation active est repérée. À la veille de l'annonce, les branches maintenues étaient PHP 8.2, 8.3, 8.4 et 8.5, dans leurs versions 8.2.34, 8.3.35, 8.4.26 et 8.5.11, publiées le 24 septembre.

Pourquoi tout le monde surveille l'heure

Selon Ars Technica, l'avertissement a suivi la fuite d'informations non confirmées : une vidéo montrant un outil baptisé « PHP2Shell » exécuter du code à distance sur des serveurs WordPress, MediaWiki, phpBB, Magento, Joomla, Laravel, Symfony, Drupal ou WHMCS. La société de sécurité watchTowr associe l'alerte à deux identifiants, CVE-2026-109618 et CVE-2026-109619, décrits comme des exécutions de code à distance. Le rapport à l'origine de la fuite affirme que toutes les versions depuis PHP 5 seraient touchées ; ni l'étendue, ni la cause technique n'étaient confirmées par PHP au moment de notre contrôle. Au 21 octobre, watchTowr ne signalait aucune exploitation constatée.

Ce que tu peux faire avant 16 h

Pas de correctif à appliquer avant la publication officielle, et surtout pas de « patch » trouvé sur un réseau social. Le travail utile se fait en amont :

• Inventorier tous les endroits où PHP tourne : serveurs, conteneurs Docker, hébergements mutualisés, sites WordPress ou boutiques en ligne oubliés, outils internes.
• Préparer le chemin de mise à jour : paquets de ta distribution Linux, images Docker officielles, ou communication de ton hébergeur si tu es en mutualisé. Distributions et images reprennent les correctifs avec leur propre délai : surveille leur canal de sécurité.
• Prévoir une fenêtre de redémarrage des services PHP (PHP-FPM, Apache avec mod_php) et un test rapide des sites après la mise à jour.

Notre lecture

Analyse. Annoncer une date et une heure laisse le temps aux administrateurs de s'organiser, mais signale aussi aux attaquants qu'une cible arrive. Les heures qui suivent la publication sont les plus délicates : un correctif publié peut être comparé au code précédent, ce qui aide à retrouver la faille. Pour un site exposé sur Internet, l'objectif raisonnable est d'appliquer la mise à jour le jour même, en commençant par les applications publiques. Nous compléterons cet article avec les versions corrigées dès leur publication.