Failles PHP critiques : pourquoi une mise à jour du CMS ne suffit pas
Deux vulnérabilités peuvent permettre à des attaquants d'exécuter du code sur des serveurs web. Des correctifs sont disponibles. Pour les exploitants de sites suisses, c'est désormais l'environnement d'exécution réellement utilisé qui compte.
Le projet PHP a publié le 21 octobre 2026 des mises à jour de sécurité contre deux vulnérabilités critiques. Dans certaines conditions, ces failles peuvent permettre à des attaquants d'exécuter du code sur un serveur web sans s'authentifier. Pour les exploitants de boutiques en ligne, de sites d'associations ou de services numériques en Suisse, c'est donc le logiciel serveur employé qui est déterminant, et non le seul site visible.
Les correctifs sont contenus dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les deux failles sont répertoriées sous CVE-2026-109618 et CVE-2026-109619. L'avertissement commun d'organes européens de cybersécurité, dont l'ENISA et le CERT-EU, appelle les organisations à agir sans délai. Les systèmes accessibles publiquement sont prioritaires.
La faille se situe sous le CMS
PHP est un langage de programmation doté d'un environnement d'exécution sur le serveur. De nombreuses applications web reposent sur lui. Un exploitant peut donc recourir à PHP sans programmer lui-même le langage. Selon le contrat, la responsabilité de la mise à jour technique incombe à l'hébergeur, à une agence mandatée ou à sa propre équipe informatique.
Dans son propre avis de sécurité, WordPress précise qu'il ne s'agit pas de failles spécifiques à WordPress. Une mise à jour de WordPress n'est ni prévue ni nécessaire pour ces failles. C'est l'installation PHP qui doit être corrigée. Dans la rubrique « Santé du site » de WordPress, il est possible de consulter des indications sur la version du serveur ; de nombreuses interfaces d'hébergement les affichent également.
Pour une petite entreprise, une question précise est donc plus utile que l'assurance générale que le site est à jour : quelle version de PHP sert l'application publique, et quel correctif le fournisseur a-t-il appliqué ? L'actualité des extensions et du CMS reste importante, mais elle ne répond pas à cette autre question.
Les numéros de version exigent le bon contexte
Qui utilise les versions originales du projet PHP peut comparer avec les publications corrigées mentionnées. Pour les distributions Linux et les paquets de fournisseurs suivis sur le long terme, des correctifs de sécurité peuvent aussi être rétroportés dans des séries de paquets existantes. L'avis de sécurité du fournisseur concerné entre alors également en ligne de compte. Une version principale simplement plus ancienne ne suffit pas pour une évaluation définitive.
À l'inverse, l'absence de voie de mise à jour régulière ne signifie pas que tout danger est écarté. PHP 8.1 et les séries plus anciennes ne reçoivent plus de publications de sécurité normales de la part du projet PHP. Certains fournisseurs proposent leurs propres rétroportages. Les exploitants doivent clarifier leur validité pour l'installation utilisée ou passer à une série prise en charge et corrigée.
Tout serveur vulnérable n'est pas déjà piraté
Les failles concernent la gestion de la mémoire et le traitement des erreurs. Selon la présentation du projet PHP, le risque est particulièrement élevé avec Apache et mod_php ; d'autres modes de fonctionnement répandus de PHP doivent également être vérifiés. Pour le public, la distinction suivante est centrale : une voie d'attaque démontrée révèle un risque de sécurité réel. Elle ne prouve pas que chaque site concerné a déjà été compromis.
L'ENISA recommande de recenser les applications et les prestataires et d'appliquer les mises à jour. Lorsqu'une correction rapide n'est pas possible, les organisations devraient envisager d'isoler provisoirement du réseau public les applications concernées. Le projet PHP souligne pour sa part que des mesures de configuration provisoires ne réduisent que certaines voies d'attaque et ne remplacent pas une protection complète.
Une confirmation traçable devrait consigner quel système a été vérifié et à quel niveau il a été porté. Pour les services externalisés, aucune lacune de responsabilité ne doit subsister entre l'agence et l'hébergeur. Le recensement recommandé par les instances européennes sert précisément à retrouver PHP dans des produits qui portent un autre nom à première vue.
L'IA trouve les failles, les humains assurent la correction
OpenAI rapporte que l'entreprise de sécurité Calif a examiné une faille critique à l'aide d'un modèle d'IA et que Wiz a signalé les deux vulnérabilités de manière indépendante. Il s'agit de la présentation d'une entreprise impliquée. Elle ne doit pas être confondue avec l'affirmation qu'une IA aurait découvert et résolu le problème à elle seule.
La PHP Foundation décrit une genèse plus longue : les premiers signes de l'un des problèmes sont apparus dès 2024. La compatibilité, d'éventuels effets secondaires et des ressources spécialisées limitées ont compliqué la décision de corriger. La fondation reconnaît des erreurs structurelles et fait état de procédures modifiées. Cela limite le récit simpliste d'une sécurité automatique.
Pour les exploitants suisses, il en découle une tâche vérifiable : définir les responsabilités, recenser les environnements d'exécution concernés et faire confirmer le correctif installé. Un nom de produit rassurant ou une mise à jour réussie du CMS ne suffit pas. Ce qui compte, c'est de savoir si le logiciel qui traite réellement les requêtes publiques a bien été corrigé.
