Le 21 octobre 2026, le projet PHP a publié des correctifs pour deux vulnérabilités critiques pouvant permettre à un attaquant distant non authentifié d’exécuter du code sur un serveur. L’alerte concerne PHP lui-même, le langage qui fait fonctionner WordPress, et non une faille propre au CMS. Mettre à jour le tableau de bord, les extensions et le thème reste indispensable, mais cela ne remplace donc pas la mise à jour de PHP chez l’hébergeur.
Pour une PME ou une agence, la priorité est de vérifier quelle version de PHP exécute réellement le site, de demander confirmation à l’hébergeur, puis de planifier une mise à jour contrôlée et des tests. Voici une méthode concrète pour ne pas confondre maintenance WordPress et maintenance de l’environnement serveur.
Deux failles dans PHP, pas dans WordPress
Ce qui a été corrigé le 21 octobre 2026
Le projet PHP a publié des versions correctives pour les branches 8.2, 8.3, 8.4 et 8.5 : respectivement PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Les failles, identifiées comme CVE-2026-109618 et CVE-2026-109619, concernent la gestion interne de la mémoire et de l’état des requêtes. Elles peuvent ouvrir une voie à l’exécution de code à distance sans authentification. Le projet PHP indique que les installations qui reçoivent des requêtes web sont concernées, quels que soient certains modes d’exécution utilisés, comme PHP-FPM ou Apache avec mod_php. L’avis de sécurité du projet PHP recommande une mise à jour immédiate.
Pourquoi une mise à jour WordPress ne corrige pas cette faille
WordPress est une application qui s’exécute au-dessus de PHP. Lorsqu’une requête arrive au serveur, le moteur PHP intervient pour la traiter ; le code de WordPress ne peut pas remplacer ni réparer le binaire PHP installé sur le serveur. L’équipe WordPress confirme que ces vulnérabilités ne sont pas spécifiques à WordPress et qu’aucune mise à jour du CMS n’est prévue pour les corriger. Son avis aux propriétaires de sites invite à vérifier la version avec l’hébergeur et à mettre PHP à jour si nécessaire.
En pratique, les deux couches ont des responsabilités différentes :
- Maintenance WordPress : mise à jour du cœur, des extensions et du thème ; vérification des comptes, des sauvegardes et du fonctionnement du site.
- Maintenance serveur : version de PHP, configuration du moteur, extensions PHP, serveur web, système d’exploitation et protections mises en place par l’hébergeur.
Une version récente de WordPress n’est donc pas une preuve que PHP est corrigé. Inversement, un PHP à jour ne dispense pas de maintenir WordPress.
Vérifier la version réellement utilisée par le site
Commencer dans l’administration WordPress
Connectez-vous au tableau de bord puis ouvrez Outils > Santé du site > Informations > Serveur. Relevez la version PHP indiquée. WordPress précise que cette page permet de consulter la version utilisée par le site ; de nombreux hébergeurs l’affichent également dans leur panneau de gestion. Cette vérification donne un premier indice, mais ne remplace pas une confirmation de l’hébergeur lorsqu’une mise à jour serveur est requise.
Notez le nom de domaine, la version PHP observée et la date de vérification. Si vous gérez plusieurs sites, faites ce relevé pour chaque installation : un même compte d’hébergement peut héberger plusieurs domaines, sous-domaines ou environnements avec des réglages distincts.
Demander une confirmation écrite à l’hébergeur
Si vous n’avez pas accès à l’administration WordPress, ou si le site est critique, contactez directement le support. Ne demandez pas seulement si « PHP est à jour ». Faites préciser la version effective pour le domaine concerné, si le correctif de sécurité du 21 octobre 2026 est installé et si le changement nécessite une action de votre part.
Vous pouvez envoyer ce message :
Bonjour, pouvez-vous confirmer la version PHP actuellement exécutée par le site [nom de domaine], ainsi que l’application du correctif qui concerne CVE-2026-109618 et CVE-2026-109619 ? Si une mise à jour est nécessaire, merci de préciser la version cible, la procédure, l’éventuelle interruption de service et la possibilité de revenir temporairement à la configuration précédente en cas d’incompatibilité.
Demandez aussi si les sites de test et de préproduction utilisent la même version. Une version PHP affichée dans un panneau de contrôle peut parfois correspondre à une version configurée, et non à celle qui traite effectivement les requêtes du site ; en cas de doute, demandez explicitement au support de vérifier le runtime actif.
Planifier la mise à jour PHP sans improviser
Établir l’inventaire et préparer un retour arrière
Avant toute modification, identifiez les sites concernés et les personnes responsables : propriétaire de l’activité, agence, administrateur technique et hébergeur. Vérifiez les sauvegardes récentes des fichiers et de la base de données, et confirmez qu’elles peuvent être restaurées. Si l’hébergeur propose une préproduction, appliquez-y d’abord le changement. L’objectif n’est pas de retarder un correctif critique, mais de réduire le risque qu’une incompatibilité bloque une boutique ou un formulaire au moment du basculement.
Rassemblez les informations utiles : extensions et thème actifs, version de WordPress, fonctionnalités essentielles et connexions externes. Portez une attention particulière aux modules anciens ou développés sur mesure. Si votre site est géré par une agence, clarifiez qui effectue le changement : le fournisseur d’hébergement ou l’équipe qui maintient le site.
Choisir une version corrigée et adaptée
Pour les branches mentionnées dans l’avis PHP du 21 octobre, les versions correctives publiées sont 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Ces numéros correspondent aux versions publiées à cette date ; demandez à l’hébergeur quelle version corrigée et prise en charge est disponible pour votre environnement. Ne choisissez pas une version expérimentale pour un site de production et ne changez pas de branche sans vérifier la compatibilité des extensions et du code personnalisé.
PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour de sécurité du projet PHP. Des distributions ou fournisseurs à support prolongé peuvent toutefois proposer des correctifs rétroportés. Si votre site utilise une ancienne version, ne présumez pas qu’elle est protégée : demandez au fournisseur de confirmer explicitement le correctif appliqué et préparez la migration vers une version prise en charge. L’avis WordPress recommande une réaction particulièrement prudente lorsque le site utilise une version antérieure à 8.2 et que l’organisation gère elle-même son hébergement.
Procéder par étapes et garder une trace
- Confirmez la sauvegarde et la procédure de restauration.
- Appliquez le changement sur un environnement de test lorsqu’il est disponible.
- Testez les fonctions principales et surveillez les journaux d’erreurs.
- Planifiez le basculement en production avec l’hébergeur ou le responsable technique.
- Vérifiez à nouveau la version réellement utilisée après le changement, puis consignez la date, la version et le résultat des contrôles.
Si le fournisseur gère automatiquement les correctifs, cela ne signifie pas qu’il a déjà modifié chaque environnement. Obtenez une confirmation spécifique au site et conservez-la dans votre suivi de maintenance.
Tester le site après le changement
Vérifier les parcours qui comptent pour l’activité
Une page d’accueil qui s’affiche n’est pas un test suffisant. Après la mise à jour, contrôlez les parcours réels de vos visiteurs et de votre équipe. Pour une boutique, vérifiez le catalogue, le panier, le paiement et les courriels de commande. Pour un site de services, testez les formulaires, leur réception et les pages de confirmation. Pour un site avec espace membre, vérifiez la connexion, la récupération de mot de passe et les contenus réservés.
- Parcourez quelques pages sur ordinateur et mobile.
- Envoyez un formulaire de test et confirmez sa réception.
- Vérifiez les fonctions connectées à un service externe, comme la prise de rendez-vous ou l’envoi d’e-mails.
- Consultez Santé du site, les journaux disponibles et les éventuelles alertes de l’hébergeur.
- Surveillez les erreurs ou comportements anormaux après le basculement.
Si un dysfonctionnement apparaît, notez l’heure, l’action effectuée et le message d’erreur, puis contactez l’hébergeur ou le prestataire technique. Ne désactivez pas en bloc les extensions sur le site de production sans plan de diagnostic : cela peut interrompre des fonctions commerciales ou masquer la cause du problème.
Ne pas confondre mesure temporaire et correctif
L’avis PHP décrit certaines mesures de réduction d’exposition lorsque la mise à jour immédiate n’est pas possible, mais précise qu’elles ne rendent pas une installation sûre et qu’aucune mesure ne remplace le correctif. Ces réglages relèvent de l’administration serveur et ne doivent pas être copiés au hasard dans un fichier de configuration WordPress. La réponse prioritaire est de demander au fournisseur l’application d’une version corrigée ou une solution de remplacement validée par ses équipes.
Encadré pratique — votre contrôle en 15 minutes : relevez la version PHP dans Santé du site, identifiez le fournisseur d’hébergement, demandez une confirmation pour les deux CVE, vérifiez la sauvegarde et inscrivez le test des parcours prioritaires au calendrier. Si la version est antérieure à 8.2, ou si le fournisseur ne peut pas confirmer le correctif, faites escalader le dossier sans attendre une simple mise à jour WordPress.
Organiser une maintenance distincte pour WordPress et l’hébergement
Créer une routine compréhensible par toute l’équipe
La sécurité ne devrait pas dépendre d’une vérification ponctuelle après une alerte. Dans votre procédure de maintenance, séparez les tâches du CMS de celles de l’hébergement et attribuez un responsable à chacune. Un tableau de suivi peut contenir le domaine, la version WordPress, la version PHP, le fournisseur, la date de vérification, la date de sauvegarde et le résultat des tests. Prévoyez un contact de secours lorsque le prestataire habituel est indisponible.
Pour structurer la maintenance de votre site ou planifier une évolution, consultez nos services de création et développement web et l’ensemble de nos services numériques. Les équipes qui souhaitent gagner en autonomie peuvent également découvrir nos formations professionnelles.
Si la situation révèle un retard plus large, un contrôle de sécurité et de compatibilité peut aider à prioriser les actions : mises à jour WordPress, extensions, sauvegardes, hébergement et tests. Pour prévenir les incidents, vous pouvez aussi lire notre article sur les contrôles à demander à votre hébergeur après les correctifs PHP et celui consacré aux vérifications PHP et à la sécurisation du site.
Questions fréquentes
Une mise à jour WordPress suffit-elle à corriger ces deux failles ?
Non. Les vulnérabilités concernent le moteur PHP du serveur, pas le code de WordPress. Il faut vérifier et mettre à jour PHP auprès de l’hébergeur ou du responsable serveur. Les mises à jour WordPress restent nécessaires pour les autres correctifs.
Comment connaître la version PHP utilisée par mon site ?
Dans WordPress, ouvrez Outils > Santé du site > Informations > Serveur. Vous pouvez également consulter le panneau de votre hébergeur. En cas de doute, demandez au support de confirmer la version qui traite effectivement les requêtes de votre domaine.
Quelles versions corrigées ont été publiées le 21 octobre 2026 ?
Le projet PHP a publié PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12 pour corriger les deux vulnérabilités sur ces branches. Pour une version antérieure, demandez au fournisseur s’il fournit un correctif rétroporté ou s’il faut migrer vers une branche prise en charge.
Que faire si mon hébergeur ne répond pas ou ne peut pas mettre à jour PHP ?
Relancez le support par un canal permettant de conserver une trace et demandez une échéance ainsi qu’une solution technique. Si vous gérez vous-même le serveur et ne pouvez pas appliquer un correctif, faites évaluer rapidement le risque par un administrateur qualifié ; l’avis WordPress recommande d’envisager la mise hors ligne d’un serveur vulnérable lorsqu’une remédiation immédiate n’est pas possible.
Dois-je tester le site même si l’hébergeur a effectué la mise à jour ?
Oui. Confirmez d’abord la version active, puis testez les fonctions essentielles à votre activité : formulaires, commandes, paiements, connexions et envois d’e-mails. Une mise à jour réussie doit être suivie d’une vérification opérationnelle.
Conclusion : vérifiez les deux couches, pas seulement le CMS
Les correctifs PHP publiés le 21 octobre 2026 rappellent une distinction importante : WordPress et son environnement serveur sont deux éléments différents à maintenir. La bonne démarche consiste à relever la version PHP, obtenir une confirmation précise de l’hébergeur, planifier une mise à jour corrigée et tester les parcours essentiels du site. Si vous souhaitez clarifier les responsabilités ou faire vérifier votre installation, contactez Enovatic pour échanger sur vos besoins.
Sources
- www.php.net — https://www.php.net/archive/2026.php
- wordpress.org — https://wordpress.org/news/2026/10/critical-php-security-release/
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 : Lazar Stankovic sur Unsplash.
