PHP : deux failles critiques, le correctif attendu mercredi

Le projet PHP doit publier une mise à jour de sécurité d’urgence le 21 octobre 2026 à 14h00 UTC. Elle doit corriger deux vulnérabilités critiques, toutes deux évaluées à 9,2 selon le score CVSS v4.0.

Dans son avis préalable, PHP n’a pas encore détaillé les versions affectées ni publié les identifiants des vulnérabilités. Des chercheurs et plusieurs acteurs de la cybersécurité associent toutefois ces failles aux identifiants CVE-2026-109618 et CVE-2026-109619.

Les vulnérabilités sont présentées comme des failles d’exécution de code à distance (RCE), potentiellement exploitables sans authentification. Selon les scénarios décrits par les sources de sécurité, un attaquant pourrait prendre le contrôle du processus PHP, déposer un logiciel malveillant ou compromettre le serveur qui héberge une application web.

Un risque qui dépasse les applications PHP visibles

PHP est utilisé directement par de nombreux sites et applications, mais aussi intégré à des solutions qui ne mettent pas nécessairement cette dépendance en évidence. La BBC cite notamment WordPress, Drupal, Joomla, Magento, les plateformes d’hébergement mutualisé et certains panneaux d’administration.

Cette présence dans des chaînes logicielles complexes complique l’inventaire des systèmes exposés. Une organisation peut utiliser PHP à travers un CMS, une appliance, une interface d’administration ou un service fourni par un prestataire sans disposer d’une visibilité immédiate sur la version exécutée.

Le CERT-EU estime que le niveau de risque annoncé correspond à un potentiel d’exécution de code à distance sans authentification. Le Centre national britannique de cybersécurité, le NCSC, recommande de suivre la publication du correctif et d’envisager la mise hors ligne des systèmes qui ne peuvent pas être protégés immédiatement.

Des attaques préliminaires signalées

La publication des détails techniques aurait été précédée par une fuite d’informations et d’un code de preuve de concept associé au nom PHP2Shell. La BBC rapporte que Cloudflare observe déjà des attaques préliminaires et adapte ses mesures de protection à l’apparition de nouveaux vecteurs.

Cette situation est importante pour les exploitants : le risque ne se limite plus à une vulnérabilité théorique annoncée à l’avance. Les organisations doivent se préparer à appliquer le correctif dès sa disponibilité et à rechercher d’éventuels signes de compromission dans leurs environnements exposés.

Les informations disponibles ne permettent toutefois pas encore de mesurer précisément l’ampleur des attaques ni de confirmer que tous les systèmes PHP sont affectés de la même manière. Le projet PHP doit publier les versions concernées et les correctifs détaillés avec la mise à jour d’urgence.

Les contournements ne remplacent pas le correctif

Des règles de pare-feu applicatif, des modifications de configuration ou des restrictions de fonctions PHP ont été évoquées avant la publication du correctif. Plusieurs signalements spécialisés indiquent toutefois que ces mesures ne constituent pas une protection fiable contre les vecteurs actuellement observés.

The News rapporte notamment que les règles WAF et les contournements précédemment proposés ne protègent pas suffisamment les installations exposées. Cette information est attribuée à la source et ne remplace pas une validation technique propre à chaque environnement.

Les équipes de sécurité ne devraient donc pas considérer une modification de configuration comme un substitut au correctif officiel.

Ce que les équipes doivent préparer

• inventorier les serveurs, CMS, appliances et applications qui exécutent PHP ;
• identifier les versions utilisées, y compris dans les composants fournis par des prestataires ;
• repérer les applications PHP accessibles depuis Internet ;
• préparer un plan de mise à jour et de redémarrage ;
• vérifier les mécanismes de restauration et les sauvegardes ;
• renforcer la surveillance des journaux web, PHP, système et réseau ;
• limiter temporairement l’exposition des applications qui ne sont pas indispensables ;
• envisager la mise hors ligne des services qui ne peuvent pas être isolés ou protégés immédiatement.

Après l’installation du correctif, l’analyse doit se poursuivre. Le NCSC recommande de surveiller les avis de sécurité des éditeurs tiers qui intègrent ou embarquent PHP.

Les équipes doivent également rechercher les signes d’une compromission antérieure : fichiers récemment créés ou modifiés, web shells, comptes administrateurs inattendus, tâches planifiées inhabituelles, connexions sortantes anormales et accès suspects aux journaux.

Les versions anciennes posent un problème particulier

Les informations publiées par les sources secondaires indiquent que les versions anciennes de PHP pourraient être concernées, tandis que les branches encore supportées devraient être les premières à recevoir les correctifs officiels.

Cette distinction devra être confirmée par l’avis de sécurité publié par PHP. Les environnements utilisant PHP 8.1, PHP 7 ou PHP 5 pourraient ne pas bénéficier d’un correctif officiel du cœur de PHP. Les exploitants devront alors envisager une migration, une isolation forte ou le remplacement du composant exposé.

Tant que PHP n’a pas publié la liste définitive des versions concernées et les correctifs correspondants, il est prématuré de conclure qu’une branche particulière est épargnée.

Sources

• PHP — avis préalable sur la mise à jour critique, 20 octobre 2026
• BBC — vulnérabilités critiques de PHP et recommandations des autorités, 21 octobre 2026
• The News — vulnérabilités PHP critiques et mesures recommandées, 21 octobre 2026
• OX Security — CVE-2026-109618 et CVE-2026-109619
• Image : 123Net, Wikimedia Commons, licence CC BY-SA 3.0.