Une mise à jour de WordPress ne met pas automatiquement à jour PHP. Pourtant, PHP est le moteur qui exécute WordPress sur le serveur : si cette couche reste vulnérable, actualiser le CMS et ses extensions ne suffit pas à corriger le problème côté hébergement.
Les 20 et 21 octobre 2026, l’équipe PHP a annoncé puis publié des mises à jour de sécurité pour corriger deux failles critiques, référencées CVE-2026-109618 et CVE-2026-109619. Elles peuvent permettre l’exécution de code à distance sans authentification. PHP recommande aux utilisateurs des versions concernées d’installer les correctifs disponibles, sans compter sur une mesure de contournement comme remplacement de la mise à jour. Pour une PME, l’enjeu immédiat est donc simple : savoir quelle version de PHP sert réellement le site, obtenir une confirmation vérifiable et s’assurer qu’une restauration est possible si la mise à jour entraîne un incident.
Ce guide vous aide à organiser ces vérifications avec votre hébergeur ou votre prestataire, sans manipuler vous-même la configuration du serveur si vous n’en avez pas la responsabilité.
Pourquoi une mise à jour WordPress ne suffit pas
WordPress et PHP sont deux couches différentes
WordPress est un logiciel installé sur votre hébergement. PHP, lui, est un langage et un environnement d’exécution configuré côté serveur. Le site dépend des deux : WordPress doit être maintenu, mais le serveur doit également utiliser une version de PHP corrigée et prise en charge.
Mettre à jour WordPress, un thème ou une extension ne remplace donc pas une mise à jour de PHP. À l’inverse, mettre PHP à niveau ne met pas automatiquement à jour le cœur WordPress ni les extensions. Ces opérations sont liées dans une démarche de maintenance, mais elles sont distinctes et peuvent relever d’intervenants différents.
Ce que l’alerte d’octobre signifie pour votre site
Les avis publiés par PHP concernent les installations PHP qui traitent des requêtes web. Les mises à jour correctives annoncées couvrent notamment les branches 8.2, 8.3, 8.4 et 8.5 : les versions correctives indiquées sont respectivement 8.2.35, 8.3.36, 8.4.27 et 8.5.12. La version à installer dépend de la branche utilisée et de la manière dont l’hébergeur distribue ses correctifs. N’appliquez pas ces numéros sans vérifier votre environnement : la meilleure référence est la confirmation de votre hébergeur ou de votre administrateur système.
L’équipe PHP indique que les failles peuvent mener à une exécution de code à distance sans authentification. Cela justifie une vérification rapide, mais ne permet pas de conclure que votre site a été attaqué. Le bon réflexe consiste à confirmer l’exposition, le correctif appliqué et les mesures de suivi, sans dramatiser ni supposer que le site est compromis.
Étape 1 : identifier la version de PHP réellement utilisée
Consultez les informations de votre hébergement
Commencez par l’espace client de votre hébergeur. Selon le fournisseur, la version peut apparaître dans une rubrique nommée « PHP », « Configuration », « Environnement », « Gestion du site » ou « MultiPHP ». Notez le nom de domaine concerné, la version affichée et, si l’information existe, la date de dernière modification.
Vérifiez le bon environnement : une entreprise peut avoir plusieurs sites, un environnement de test, une préproduction et des sous-domaines. La version PHP d’un site de test ne prouve pas que celle du site public est identique. Un même compte peut aussi héberger plusieurs applications configurées séparément.
Demandez une confirmation si l’information n’est pas claire
Si l’interface ne montre qu’une version « recommandée » ou « disponible », ne la confondez pas avec la version effectivement active. Demandez à votre hébergeur ou prestataire de confirmer la version qui exécute les requêtes du site en production et si le correctif correspondant est installé.
Vous pouvez envoyer ce message :
« Pour le site [nom de domaine], pouvez-vous confirmer la version de PHP effectivement utilisée en production, la branche concernée et la version corrective installée pour les failles CVE-2026-109618 et CVE-2026-109619 ? Merci de préciser la date de mise à jour, si le correctif est appliqué au serveur qui traite le trafic web, et si une sauvegarde restaurable a été vérifiée. »
Évitez de créer une page publique affichant des informations détaillées sur le serveur. Si votre prestataire doit réaliser un contrôle technique, demandez-lui de vous transmettre le résultat par un canal privé, puis de supprimer tout fichier temporaire utilisé.
Étape 2 : faire appliquer le correctif sans créer un nouvel incident
La mise à jour relève souvent de l’hébergeur
Sur un hébergement mutualisé, l’équipe de l’hébergeur gère généralement PHP. Sur un serveur privé ou dédié, la responsabilité peut relever de votre prestataire, de votre équipe informatique ou de l’entreprise qui administre le serveur. Le fait de pouvoir choisir une version dans une interface ne signifie pas forcément que le correctif est déjà installé : demandez ce qui est activé pour votre site et quand la modification prendra effet.
La demande doit porter sur le correctif de sécurité de la branche utilisée, et non uniquement sur un changement vers la version la plus récente de PHP. Une montée vers une nouvelle branche peut provoquer des incompatibilités avec certaines extensions, certains thèmes ou du code spécifique. L’objectif immédiat est d’obtenir une version corrigée et prise en charge, puis de planifier séparément toute migration majeure nécessaire.
Prévoir un contrôle fonctionnel après intervention
Après la mise à jour, parcourez les fonctions essentielles de votre site, idéalement avec votre prestataire : page d’accueil, formulaires, connexion à l’administration, recherche, réservation, paiement et envoi des courriels. Pour une boutique, vérifiez aussi le panier et le parcours de commande dans un environnement adapté, sans créer de transactions réelles inutiles.
Surveillez les erreurs signalées par votre outil de suivi ou par l’hébergeur. Si le site ne fonctionne plus normalement, contactez la personne qui a effectué l’intervention avant de modifier plusieurs réglages simultanément. Votre prestataire web peut vous aider à coordonner la vérification du site et la communication avec l’hébergeur.
Étape 3 : vérifier les sauvegardes et la procédure de retour arrière
Une sauvegarde doit pouvoir être restaurée
Une sauvegarde annoncée n’est utile que si elle est récente, complète et restaurable. Avant une intervention sur le serveur ou une évolution de version, demandez si les fichiers du site et la base de données sont sauvegardés, où les copies sont conservées, combien de temps elles sont gardées et qui peut déclencher une restauration.
La restauration n’est pas un substitut à l’installation du correctif de sécurité : elle sert à revenir à un état fonctionnel si une mise à jour provoque une incompatibilité. Elle ne devrait pas conduire à réactiver durablement un environnement vulnérable. Convenez à l’avance de la marche à suivre si le site rencontre un problème après l’opération.
Formalisez les responsabilités
Pour éviter que chacun pense que l’autre s’en occupe, identifiez clairement les responsabilités :
- Hébergeur : correctifs et configuration de PHP au niveau du serveur, selon le contrat.
- Prestataire web : compatibilité du site, des extensions et du thème, tests après intervention, selon la mission convenue.
- Entreprise : validation des priorités, accès aux contacts, décision sur les périodes d’intervention et conservation des preuves de suivi.
Consignez la date, la version confirmée, le nom de l’intervenant et les tests réalisés. Ce relevé facilite les prochains contrôles et évite de refaire les mêmes vérifications dans l’urgence.
Votre contrôle express : les questions à poser
Utilisez cette liste lors de votre échange avec l’hébergeur ou le prestataire :
- Quelle version de PHP exécute actuellement mon site public ?
- Le serveur qui reçoit les requêtes web dispose-t-il du correctif contre CVE-2026-109618 et CVE-2026-109619 ?
- La confirmation concerne-t-elle bien le bon domaine et le bon environnement ?
- Une sauvegarde récente des fichiers et de la base de données existe-t-elle ?
- La restauration a-t-elle été testée ou la procédure est-elle clairement définie ?
- Qui contrôle les fonctionnalités du site après la mise à jour, et qui dois-je contacter en cas d’erreur ?
Encadré pratique : archivez la réponse de l’hébergeur ou du prestataire avec la date de vérification. Une confirmation écrite indiquant le domaine, la version PHP et le correctif appliqué est plus utile qu’un simple « c’est à jour ». Si vous ne savez pas qui gère PHP, commencez par demander à votre fournisseur d’hébergement qui est responsable des mises à jour de sécurité du serveur.
Questions fréquentes
La mise à jour automatique de WordPress corrige-t-elle PHP ?
Non. WordPress et PHP sont des couches différentes. Une mise à jour de WordPress, de thème ou d’extension ne prouve pas que le serveur utilise une version corrigée de PHP. Il faut vérifier les deux séparément.
Dois-je changer moi-même la version PHP dans mon espace client ?
Pas sans vérifier les responsabilités et la compatibilité du site. Demandez d’abord à l’hébergeur quelle version corrigée est disponible et à votre prestataire si le site est prêt pour le changement. Sur un serveur administré, une intervention directe peut avoir des conséquences sur plusieurs applications.
Que faire si mon hébergeur ne répond pas rapidement ?
Relancez le support en mentionnant les CVE-2026-109618 et CVE-2026-109619, le nom de domaine et la date de votre première demande. Demandez une confirmation explicite de la version active et du correctif. Si votre site est géré par un prestataire, sollicitez-le en parallèle pour clarifier qui peut intervenir sur le serveur.
Comment savoir si mon site a été compromis ?
La présence d’une version vulnérable ne prouve pas qu’une attaque a réussi. Si vous observez des comptes inconnus, des changements inattendus ou des comportements anormaux, contactez sans délai votre prestataire et votre hébergeur. Ils pourront examiner les journaux et les fichiers, sécuriser les accès et déterminer les mesures adaptées.
Faut-il aussi mettre à jour les extensions WordPress ?
Oui, les extensions et le thème doivent faire partie de votre maintenance habituelle, mais leur mise à jour ne remplace pas le correctif PHP. Pour organiser la gestion de votre site, découvrez nos formations WordPress et nos services web.
Conclusion : obtenir une confirmation, pas seulement une promesse
Les correctifs PHP annoncés les 20 et 21 octobre 2026 rappellent qu’un site WordPress dépend aussi de son environnement serveur. Pour agir efficacement, identifiez la version réellement utilisée, faites confirmer par écrit que le bon serveur est corrigé, puis vérifiez les sauvegardes et les tests après intervention. Ces étapes sont accessibles à une PME, même si la mise à jour elle-même doit être confiée à la personne qui administre l’hébergement.
Vous ne savez pas qui est responsable de PHP ou souhaitez faire vérifier votre site et son suivi technique ? Contactez Enovatic pour discuter de vos besoins.
Sources : annonces et avis de sécurité PHP ; actualités de sécurité WordPress.
Sources
- www.php.net — https://www.php.net/archive/2026.php
- wordpress.org — https://wordpress.org/news/category/security/
- www.php.net — https://www.php.net/
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 : JC Daily sur Unsplash.
