Failles critiques PHP - des informations fuitent avant les correctifs, l’équipe sécurité lance l’alerte

Des informations sur deux failles critiques PHP ont fuité avant la publication des correctifs. Les identifiants relayés sont CVE-2026-109618 et CVE-2026-109619. watchTowr confirme la réalité de vulnérabilités d’exécution de code à distance, tandis que l’équipe sécurité de PHP appelle les administrateurs à préparer leurs mises à jour. Déclaration de watchTowr, alerte de The PHP Foundation.

Les correctifs sont annoncés pour le 21 octobre 2026 à 16h, heure de Paris. Les deux vulnérabilités sont classées critiques, avec un score officiel de 9,2/10 en CVSS v4.0. Les conditions précises d’exploitation seront publiées avec les mises à jour. Annonce officielle PHP.

Pour les équipes qui exploitent des sites et des applications PHP, le travail commence maintenant : retrouver les environnements concernés, préparer les tests et savoir qui pourra appliquer les correctifs dès leur disponibilité.

Une fuite d’informations sous embargo, pas une annonce de vol de données

Dans sa déclaration publique, watchTowr indique que des informations ont circulé avant la levée prévue de l’embargo. L’entreprise confirme qu’il s’agit de failles permettant une exécution de code à distance, ou RCE, mais ne dévoile pas leur fonctionnement.

Un embargo sert à coordonner la préparation des correctifs avant de rendre les détails d’une vulnérabilité publics. Ici, l’existence des failles est connue alors que les administrateurs ne disposent pas encore des instructions complètes pour les corriger.

La fuite concerne donc des informations de sécurité. Ce n’est pas l’annonce d’une base de données PHP dérobée ni la preuve que tous les sites utilisant ce langage ont été compromis.

Ce que PHP annonce pour le 21 octobre

Le calendrier à retenir est celui de l’équipe sécurité de PHP :

• Publication prévue : mercredi 21 octobre à 14h UTC, soit 16h à Paris.
• Sévérité : deux vulnérabilités critiques, notées chacune 9,2 en CVSS v4.0.
• Informations à venir : détails techniques, versions affectées et versions corrigées.

Le projet se réserve la possibilité de publier plus tôt si des détails deviennent publics ou si une exploitation est détectée. Le score de 10/10 et le calendrier du jeudi qui circulaient dans les premiers messages ne doivent donc pas remplacer cette annonce officielle.

Au 20 octobre, il manque encore le périmètre technique nécessaire pour qualifier chaque installation. La fonction concernée, les extensions ou configurations requises et les éventuels contournements ne sont pas détaillés dans l’annonce.

WordPress, Nextcloud et outils internes : regarder aussi le moteur PHP

PHP est le moteur qui exécute le code de nombreuses applications web. Les documentations de WordPress et de Nextcloud le comptent parmi leurs prérequis.

Un site peut donc afficher une version récente de son CMS tout en reposant sur un moteur PHP qui n’a pas été mis à jour. Corriger WordPress ou ses extensions ne remplace pas une correction de PHP. Les deux niveaux doivent être suivis.

Cela donne une liste de périmètres à inventorier, pas une liste de produits dont l’exploitation serait déjà démontrée : sites publics, boutiques, applications internes et services PHP hébergés dans des conteneurs.

Le point pratique est de retrouver la version réellement utilisée par chaque application. Sur un même serveur, plusieurs versions de PHP peuvent coexister. Un contrôle en ligne de commande donne un premier repère :

php -v

Cette commande affiche la version du binaire lancé dans le terminal, comme l’indique le manuel PHP. Il faut la rapprocher de la configuration du site, de son service PHP-FPM ou de son conteneur : elle ne prouve pas à elle seule quelle version traite les requêtes web. N’ajoutez pas de page de diagnostic publique pour faire cet inventaire.

PHP 8 ne signifie pas automatiquement PHP maintenu

Les branches actuellement prises en charge par le projet sont PHP 8.2, 8.3, 8.4 et 8.5. PHP 8.0 et 8.1 figurent déjà parmi les branches abandonnées, comme PHP 5 et PHP 7. Versions maintenues, branches en fin de vie.

Il faut donc éviter de résumer la situation à « seuls les anciens PHP 5 ou 7 posent problème ». Être sur PHP 8 ne suffit pas à établir que la branche reçoit toujours les correctifs du projet.

Pour une installation ancienne, vérifiez le support effectivement assuré par la distribution ou le fournisseur et préparez sa migration. Le choix de la cible doit aussi tenir compte de la compatibilité de l’application et de ses extensions.

Préparer la correction sans attendre de découvrir son parc

Notre recommandation opérationnelle est de profiter de cette préannonce pour préparer une intervention courte et vérifiable :

1. Recenser les usages de PHP : serveurs, sites, applications, versions, conteneurs et hébergements administrés par un tiers.
2. Identifier le responsable de la mise à jour : équipe interne, infogérant ou hébergeur. Sur un mutualisé, vérifier le calendrier de prise en charge auprès du fournisseur.
3. Préparer les contrôles applicatifs : authentification, formulaires, commandes, paiements ou traitements métier selon les services. Vérifier les sauvegardes et les moyens de reprise avant l’intervention.
4. À la publication, rapprocher l’inventaire du bulletin : conditions d’exposition, version corrective ou paquet fourni pour l’environnement concerné.
5. Déployer puis contrôler les processus en service : appliquer la procédure du fournisseur, redémarrer les services concernés lorsque nécessaire et confirmer la version utilisée après intervention.

Pour Docker, mettre à jour l’hôte ne met pas à jour le PHP embarqué dans une image. Il faut récupérer une image corrigée ou reconstruire l’image applicative à partir d’une base corrigée, puis redéployer. Docker rappelle que les images sont des instantanés et recommande leur reconstruction régulière. Bonnes pratiques de construction des images.

Ce travail repose sur une connaissance de l’existant : les mêmes dépendances qu’on cherche à retrouver pendant une urgence devraient déjà figurer dans une cartographie de l’infrastructure et de ses services.

Notre lecture opérationnelle

L’alerte est suffisamment sérieuse pour préparer une mise à jour prioritaire dès maintenant. Il n’est pas nécessaire d’attendre les détails d’exploitation pour retrouver ses versions et organiser les vérifications.

Le jour de la publication, l’objectif sera de savoir quels services nécessitent une intervention, de déployer les corrections adaptées et de vérifier le retour au fonctionnement attendu. C’est le rôle d’un suivi régulier des CVE intégré à l’exploitation, plutôt qu’une réaction improvisée à chaque annonce.

Notre infogérance de serveurs Linux couvre cette continuité entre veille, maintenance et vérification des services. Vous avez besoin d’identifier vos environnements PHP ou de préparer leurs mises à jour ? Échangeons sur votre infrastructure.

Questions fréquentes

Quand les correctifs des deux failles critiques PHP sont-ils attendus ?

L’équipe sécurité de PHP annonce une publication le 21 octobre 2026 à 14h UTC, soit 16h à Paris, avec une sortie anticipée possible si des détails deviennent publics ou si une exploitation est détectée.

Quelles versions de PHP sont affectées ?

Au 20 octobre 2026, l’annonce officielle ne précise pas encore les versions affectées ni les versions corrigées. Les branches actuellement maintenues par le projet PHP sont 8.2, 8.3, 8.4 et 8.5.

Mettre à jour WordPress suffit-il à corriger une faille PHP ?

Non. WordPress et le moteur PHP sont deux composants distincts. Si la version de PHP utilisée est concernée, sa correction passe par les paquets du serveur, une image de conteneur mise à jour ou une intervention de l’hébergeur.

La fuite signifie-t-elle que des données clients ont été volées ?

Non. La fuite rapportée concerne des informations sur des vulnérabilités sous embargo. Elle ne constitue pas une annonce de vol de données clients.

Sources

• PHP - annonce de la publication de sécurité du 21 octobre 2026.
• The PHP Foundation - préannonce des deux vulnérabilités critiques.
• watchTowr - confirmation des failles RCE après une fuite sous embargo.
• PHP - branches actuellement maintenues.
• PHP - branches abandonnées.
• WordPress - prérequis techniques.
• Nextcloud - prérequis système.
• PHP - options du binaire en ligne de commande.
• Docker - reconstruction et actualisation des images.