Deux failles critiques PHP corrigées : le contrôle à demander à votre hébergeur

Les mises à jour WordPress ne corrigent pas les failles de PHP côté serveur. Voici comment vérifier la version active, demander une confirmation à votre hébergeur et tester votre site après intervention.

Mettre à jour WordPress est indispensable, mais cela ne suffit pas à protéger toutes les couches de votre site. Le 21 octobre 2026, le projet PHP a publié des correctifs pour deux vulnérabilités critiques pouvant permettre une exécution de code à distance sans authentification. Ces failles concernent PHP lui-même, et non une version particulière de WordPress : l’intervention doit donc porter sur l’environnement serveur qui exécute votre site.

Pour une PME qui confie son hébergement à un prestataire, la bonne réaction n’est pas de modifier des réglages techniques au hasard. Il faut d’abord identifier la version de PHP active, puis demander à l’hébergeur de confirmer que le correctif correspondant a été appliqué et que le site fonctionne toujours normalement. Voici une méthode simple pour effectuer ce contrôle et en garder une trace.

Pourquoi une mise à jour de WordPress ne corrige pas toujours PHP

WordPress et PHP sont deux éléments différents

WordPress est le logiciel de gestion de contenu installé sur votre hébergement. PHP est le langage et l’environnement d’exécution dont WordPress se sert pour traiter les pages, les extensions et les thèmes. Les mises à jour de WordPress corrigent le cœur de WordPress ; les mises à jour de PHP relèvent de la configuration du serveur ou de la plateforme d’hébergement.

La nuance est importante : vous pouvez avoir installé la dernière version de WordPress tout en utilisant une version de PHP qui n’a pas encore reçu le correctif nécessaire. Dans ce cas, le tableau de bord WordPress ne peut pas remplacer l’intervention de l’hébergeur. Le projet WordPress a d’ailleurs précisé qu’aucune mise à jour de WordPress n’était requise ou prévue pour corriger les vulnérabilités annoncées le 21 octobre.

Une faille PHP peut concerner d’autres applications

Le risque ne se limite pas aux sites WordPress. Tout service hébergé qui exécute une version de PHP concernée peut être exposé : boutique en ligne, application métier, espace client ou autre outil web. La mise à jour d’un CMS ne corrige donc pas, à elle seule, une faille présente dans l’environnement PHP commun du serveur.

Le projet PHP a publié des versions correctives dans plusieurs branches maintenues, notamment PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Votre objectif n’est pas de choisir vous-même un numéro au hasard : il est de demander à l’hébergeur quelle version corrigée s’applique à votre installation et de vérifier qu’elle est bien active.

Le contrôle à effectuer : version active, correctif et fonctionnement

1. Trouver la version utilisée par le site

Dans WordPress, ouvrez Outils > Santé du site > Informations > Serveur, puis repérez la version de PHP. Vous pouvez également la retrouver dans le panneau de gestion de votre hébergement. Notez le numéro complet, ainsi que la date du contrôle et le nom du site concerné.

Si votre compte héberge plusieurs sites, vérifiez-les un par un. Il est possible que chaque domaine, sous-domaine ou environnement de préproduction utilise une configuration différente. Ne partez pas du principe que tous les sites d’un même compte bénéficient automatiquement du même réglage.

2. Demander confirmation du correctif appliqué

Le numéro de version est un point de départ, mais il ne constitue pas toujours une preuve suffisante du niveau de protection : certains hébergeurs appliquent des correctifs à leurs paquets sans modifier immédiatement le numéro affiché. Demandez une confirmation écrite précisant la branche de PHP concernée, le correctif appliqué, la date de l’intervention et, si nécessaire, la mesure de protection temporaire activée.

Le projet WordPress signale que l’hébergeur peut mettre à jour PHP et déployer des règles de pare-feu applicatif (WAF) pour atténuer le risque. Toutefois, le projet PHP indique que, pour ces vulnérabilités, il n’existe pas de mesure d’atténuation complète : la mise à jour reste la solution sûre. Une règle WAF ne doit donc pas être présentée comme un remplacement définitif du correctif PHP.

3. Vérifier le site après l’intervention

Un changement de version ou de configuration PHP peut révéler des incompatibilités avec un thème, une extension ou une application ancienne. Après confirmation de l’hébergeur, effectuez un contrôle fonctionnel : affichage des pages principales, connexion à l’administration, formulaires, recherche, prise de commande et paiement si votre site vend en ligne.

Consultez également les alertes dans Santé du site et vérifiez que les tâches importantes continuent de fonctionner. Pour une boutique ou un site qui génère des demandes commerciales, faites un test réel encadré, par exemple l’envoi d’un formulaire ou une commande de test selon la procédure prévue. En cas d’erreur, transmettez à l’hébergeur l’heure du problème, l’URL concernée et le message affiché ; évitez de désactiver en urgence plusieurs extensions sans diagnostic.

Checklist courte à envoyer à votre hébergeur

Vous pouvez reprendre ce modèle dans un ticket de support ou un courriel. Remplacez les éléments entre crochets et conservez la réponse dans votre dossier de suivi du site.

Bonjour,

Pour le site [nom et domaine], pouvez-vous confirmer :

  • la version de PHP actuellement exécutée par le site, et si elle correspond bien à l’environnement de production ;
  • si le correctif de sécurité publié le 21 octobre 2026 pour les vulnérabilités CVE-2026-109618 et CVE-2026-109619 a été appliqué à cette instance ;
  • la version ou le paquet corrigé déployé, ainsi que la date et l’heure de l’intervention ;
  • si une règle WAF ou une autre mesure temporaire a été activée, et si elle sera maintenue jusqu’à la mise à jour ;
  • s’il reste une action à réaliser de notre côté et si vous avez détecté un incident lié à ces vulnérabilités.

Merci de nous indiquer également la procédure de vérification après intervention.

Comment interpréter la réponse

Une réponse utile identifie clairement le site, la configuration PHP concernée et l’action effectuée. Si le prestataire indique seulement que « le serveur est sécurisé », demandez une précision : le correctif PHP est-il appliqué, ou une mesure temporaire est-elle en place ? Quelle version est active après l’intervention ? Cette clarification permet de distinguer une mise à jour réelle d’une protection provisoire.

Si l’hébergeur vous invite à changer la version depuis son panneau, ne faites pas la bascule sans vérifier les compatibilités, surtout pour une boutique ou une application métier. Demandez si un environnement de test est disponible et si une sauvegarde exploitable a été réalisée. Si vous gérez vous-même le serveur et qu’il exécute une version ancienne non maintenue, traitez la situation comme une priorité et faites-vous assister avant d’exposer le site à de nouveaux risques.

Mettre en place un suivi qui évite les oublis

Consignez les versions et les responsabilités

Créez une fiche par site avec le domaine, le fournisseur d’hébergement, la version de PHP observée, la personne responsable des mises à jour et la date du dernier contrôle. Ajoutez-y les échanges avec le support et les éventuelles restrictions de compatibilité. Ce document simple vous évite de recommencer l’enquête lors du prochain avis de sécurité ou d’un changement de prestataire.

La responsabilité est souvent partagée : l’hébergeur gère l’infrastructure, tandis que l’entreprise ou son agence suit WordPress, les extensions et les tests fonctionnels. Faites préciser par écrit ce qui est inclus dans votre contrat : mises à jour automatiques de PHP, notification préalable, sauvegarde, environnement de test, assistance en cas d’incompatibilité et surveillance des incidents.

Ne confondez pas version récente et maintenance durable

La correction d’un incident ponctuel ne dispense pas de planifier la sortie des versions qui ne reçoivent plus de correctifs de sécurité. Au moment de la publication de l’avis WordPress, les versions de PHP antérieures à 8.2 ne recevaient déjà plus de mises à jour de sécurité du projet. PHP 8.2 devait, de son côté, atteindre sa fin de vie le 31 décembre 2026. Si votre site utilise une branche en fin de maintenance, demandez un plan de migration vers une version prise en charge et testez la compatibilité en amont.

Pour les entreprises dont le site est un outil commercial, cette démarche s’inscrit dans une gestion plus large : sauvegardes vérifiées, mises à jour de WordPress et de ses extensions, accès administrateurs maîtrisés et procédure de réaction en cas d’incident. Enovatic accompagne les professionnels dans la création et l’évolution de sites web et propose des formations pour gagner en autonomie sur les outils numériques.

Questions fréquentes

Une mise à jour de WordPress protège-t-elle contre ces failles PHP ?

Non. Ces vulnérabilités concernent PHP et l’environnement serveur. La mise à jour du cœur WordPress reste nécessaire pour d’autres raisons de sécurité, mais elle ne remplace pas le correctif PHP que doit appliquer l’hébergeur ou l’administrateur du serveur.

Où voir la version de PHP d’un site WordPress ?

Dans l’administration, ouvrez Outils > Santé du site > Informations > Serveur. Le panneau de gestion de l’hébergement peut aussi afficher cette information. Vérifiez séparément chaque site si votre compte héberge plusieurs installations.

Mon hébergeur dit qu’un WAF protège le site : est-ce suffisant ?

Demandez si le correctif PHP a également été appliqué et si le WAF n’est qu’une protection temporaire. Les indications officielles précisent qu’il n’existe pas de mesure d’atténuation complète pour ces vulnérabilités : la mise à jour PHP est la solution à privilégier.

Dois-je changer moi-même la version de PHP dans mon espace d’hébergement ?

Pas sans vérifier les conséquences. Une nouvelle version peut révéler des incompatibilités avec des extensions ou un thème ancien. Demandez d’abord conseil à l’hébergeur ou à votre agence, prévoyez une sauvegarde et testez le site après la modification.

Conclusion : demandez une confirmation précise, puis testez

Face aux failles annoncées le 21 octobre 2026, le bon réflexe est de ne pas s’arrêter au tableau de bord WordPress. Identifiez la version de PHP réellement utilisée, demandez à l’hébergeur de confirmer le correctif et sa date de déploiement, puis contrôlez le fonctionnement du site. Archivez ces éléments et clarifiez qui suivra les prochaines mises à jour.

Vous ne savez pas qui gère la version PHP de votre site, ou vous souhaitez organiser un contrôle plus complet ? Contactez Enovatic pour faire le point sur votre site et définir les prochaines actions avec votre hébergeur.

Sources : annonces de sécurité du projet PHP et avis publié par WordPress.org.

Sources

Besoin d’un accompagnement sur mesure ?

Nos experts en design, développement web et référencement accompagnent les entreprises belges au quotidien. Découvrez nos services de création de site web, nos formations professionnelles et nos réalisations.

Contactez-nous pour un devis gratuit.

Photo d'illustration : Zulfugar Karimov sur Unsplash.

Précédent WeWeb et ses garde-fous IA : comment empêcher un assistant de modifier les mauvaises parties d’une application ?