Failles critiques PHP, votre site est-il concerné ?

Votre site fonctionne et WordPress est à jour. Pourtant, la version PHP utilisée par votre serveur peut encore présenter une vulnérabilité. Le 21 octobre 2026, le projet PHP a publié des correctifs pour deux failles critiques permettant une exécution de code à distance sans authentification. Pour votre entreprise, la priorité est donc de vérifier l’environnement qui fait réellement fonctionner votre site, puis de confirmer l’application des correctifs (bulletin officiel PHP).

Quelles sont les failles PHP concernées ?

Deux défauts dans la gestion de la mémoire

La première vulnérabilité, CVE-2026-109618, concerne la gestion de données internes lorsqu’une erreur de mémoire interrompt leur initialisation. La seconde, CVE-2026-109619, peut conduire un processus à réutiliser un état interne dont la mémoire a déjà été libérée. Dans certaines conditions, ces défauts permettent d’exécuter du code sur le serveur (avis PHP sur la première faille et sur la seconde).

Une alerte à distinguer d’une compromission confirmée

Le CERT-FR a publié une alerte le 21 octobre, mise à jour le lendemain. Il signale notamment l’existence de preuves de concept pour des déploiements spécifiques. Cependant, une preuve de concept ne démontre pas que votre serveur a été attaqué : l’exposition et une éventuelle compromission doivent être examinées séparément (alerte CERTFR-2026-ALE-014).

Votre site ou votre application est-il concerné ?

Comparer les versions utilisées et les correctifs disponibles

Le CERT-FR recense les branches suivantes. Ainsi, vérifiez la version complète de chaque environnement, et pas seulement la mention « PHP 8 » dans votre espace d’hébergement.

Source : CERT-FR. Ce tableau concerne ces deux CVE ; il ne constitue pas une garantie générale de sécurité.

Tenir compte du fournisseur et des annonces complémentaires

Par ailleurs, certains fournisseurs Linux ou de maintenance longue durée proposent des correctifs rétroportés. Demandez donc la référence du paquet corrigé. PHP a également publié des précisions le 23 octobre sur une configuration particulière de sessions, puis le 26 octobre sur une dépendance Brotli des paquets Windows. Ces annonces doivent être examinées selon votre environnement (actualités de sécurité PHP).

Pourquoi mettre à jour WordPress ne suffit pas

Le site et le serveur sont deux couches différentes

WordPress, ses thèmes et ses extensions utilisent PHP, mais sa version est gérée au niveau de l’hébergement. Par conséquent, une mise à jour du CMS ne confirme pas celle du moteur PHP. La documentation WordPress recommande de vérifier les informations du serveur et de solliciter l’hébergeur pour la procédure adaptée (guide WordPress).

Où trouver la version PHP dans WordPress ?

Dans l’administration, ouvrez Outils → Santé du site → Informations → Serveur, puis recherchez la version PHP. Ensuite, faites confirmer cette information par votre hébergeur, notamment si plusieurs sites ou environnements partagent le même compte (vérifier sa version PHP).

Que demander à votre hébergeur ?

Pour commencer, demandez un état précis de vos environnements. La checklist suivante sert à organiser cet échange.

• Quels sites, applications et environnements utilisent PHP dans notre périmètre ?
• Quelle version et quel paquet sont réellement utilisés pour servir les requêtes web ?
• Les deux CVE sont-elles corrigées, et quel bulletin fournisseur le confirme ?
• Les processus, conteneurs et instances concernés ont-ils tous été relancés ou redéployés si nécessaire ?
• Les annonces complémentaires des 23 et 26 octobre s’appliquent-elles à notre configuration ?
• Quels contrôles fonctionnels et de sécurité ont été réalisés après l’intervention ?

Comment organiser la correction ?

Préparer les tests sans laisser durer l’exposition

Tout d’abord, désignez le responsable de l’intervention et identifiez les services prioritaires. Préparez ensuite une sauvegarde exploitable et des tests ciblés : connexion, formulaires, espace client ou parcours d’achat. Pour un changement de branche PHP, vérifiez également la compatibilité des extensions et du code applicatif (préparation recommandée par WordPress).

Si la compatibilité bloque la correction, convenez avec votre prestataire d’une réduction immédiate de l’exposition. En revanche, ne laissez pas un test de migration sans échéance devenir une justification au maintien d’un service vulnérable.

Valider la correction réellement en service

Après l’intervention, demandez un compte rendu indiquant les versions ou paquets installés, les instances traitées et les tests réalisés. Vérifiez ensuite les fonctions essentielles du site. Enfin, consignez les anomalies et les actions restantes, avec un responsable et une échéance.