Le 21 octobre 2026, le projet PHP a publié une alerte de sécurité concernant deux failles critiques pouvant permettre l’exécution de code à distance sans authentification. Les correctifs sont disponibles dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Pour une PME, la première action n’est donc pas de chercher une nouvelle mise à jour WordPress : il faut vérifier la version de PHP réellement utilisée par le site et faire confirmer le correctif par l’hébergeur. Le problème concerne la couche serveur et peut toucher toute application exécutée en PHP, pas uniquement WordPress.
Voici une checklist pour établir votre situation, obtenir une réponse vérifiable de votre fournisseur d’hébergement et planifier une montée de version sans provoquer de panne. L’objectif est simple : savoir ce qui tourne, ce qui a été corrigé et qui prend en charge la suite.
Ce qui est concerné : PHP, pas une mise à jour WordPress
Une faille dans le moteur qui exécute les applications
PHP est un langage utilisé par de nombreux sites et outils web. WordPress en dépend, mais PHP fonctionne au niveau du serveur : c’est l’environnement qui interprète le code lorsque le serveur traite une requête. D’autres applications, extensions, boutiques ou outils internes peuvent également s’appuyer sur PHP.
L’avis publié par le projet PHP le 21 octobre fait état de deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, susceptibles de conduire à une exécution de code à distance sans authentification. Le projet indique que les installations PHP qui répondent aux requêtes web sont concernées, notamment selon leur mode d’exécution. Il recommande une mise à jour immédiate. Les versions correctives annoncées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. ([php.net](https://www.php.net/archive/2026.php))
Pourquoi mettre WordPress à jour ne suffit pas
Une mise à jour du cœur WordPress, d’un thème ou d’une extension ne remplace pas la mise à jour de PHP. Les deux opérations concernent des composants différents : WordPress est l’application, PHP est le moteur serveur qui l’exécute. WordPress.org précise que ces vulnérabilités ne sont pas spécifiques à WordPress et qu’aucune mise à jour WordPress n’est requise pour corriger le problème. Il recommande aux propriétaires de sites de vérifier les actions de leur hébergeur et, si nécessaire, de mettre PHP à jour. ([wordpress.org](https://wordpress.org/news/2026/10/critical-php-security-release/))
Votre site peut donc afficher une version récente de WordPress tout en fonctionnant avec une version de PHP vulnérable ou dont le correctif n’a pas été confirmé. Inversement, l’hébergeur peut avoir déployé un correctif sans que vous ayez eu à intervenir dans l’administration du site. Il faut vérifier la situation réelle, plutôt que déduire le niveau de protection du seul numéro de version WordPress.
Checklist : vérifier la version PHP effectivement utilisée
1. Consultez l’administration WordPress
Si vous disposez d’un accès administrateur, WordPress permet d’afficher des informations serveur dans Outils > Santé du site > Informations > Serveur. Relevez la version de PHP indiquée et notez la date de votre vérification. La documentation d’alerte de WordPress.org mentionne aussi que certains hébergeurs affichent cette information dans leur panneau de gestion. ([wordpress.org](https://wordpress.org/news/2026/10/critical-php-security-release/))
Ne vous contentez pas d’une capture ancienne ou d’une information générale sur l’offre souscrite. Vérifiez le site concerné et, si vous gérez plusieurs sites, répétez l’opération pour chaque domaine, sous-domaine ou environnement de préproduction. Une même formule d’hébergement peut héberger plusieurs applications, avec des réglages qui ne sont pas forcément identiques.
2. Vérifiez le panneau de l’hébergeur
Dans le tableau de bord de l’hébergement, cherchez une rubrique nommée « PHP », « Configuration PHP », « Version du langage » ou « Runtime ». Notez la version active pour le domaine précis, et non une version disponible dans la liste ou recommandée pour une nouvelle installation. Si vous ne trouvez pas le réglage, ne modifiez pas au hasard une option serveur : demandez confirmation au support.
3. Consignez les éléments utiles
- Le nom de domaine et, si nécessaire, le sous-domaine concerné.
- La version PHP affichée dans WordPress et celle indiquée dans le panneau d’hébergement.
- La date de consultation et le nom du compte ou de l’offre d’hébergement.
- La présence éventuelle d’autres sites ou applications PHP sur le même hébergement.
- La personne qui suit la demande et le numéro du ticket support.
Si les deux panneaux affichent des versions différentes, demandez à l’hébergeur laquelle traite réellement les requêtes web du domaine. Une version PHP disponible dans la ligne de commande, dans un outil de diagnostic ou pour un autre site ne prouve pas nécessairement que le site public utilise la même version.
Checklist : obtenir une confirmation claire de l’hébergeur
Posez des questions précises, pas seulement « suis-je protégé ? »
Une réponse utile doit identifier le périmètre et l’action prise. Le fournisseur peut avoir mis à jour PHP, distribué un correctif adapté à sa version, ou appliqué une mesure de mitigation. Il peut aussi être en train de planifier une intervention. Demandez ce qui s’applique à votre compte et à votre configuration, sans supposer qu’une mesure temporaire équivaut à un correctif complet.
Vous pouvez envoyer ce message, en l’adaptant à votre situation :
Bonjour, pouvez-vous confirmer la version PHP qui exécute les requêtes web pour le domaine [votre domaine] et indiquer si le correctif relatif aux CVE-2026-109618 et CVE-2026-109619 est appliqué à cet environnement ? Si oui, quelle version corrigée ou quel correctif fournisseur est déployé, et à quelle date ? Si non, quel est le délai prévu et quelle action temporaire recommandez-vous ? Merci de préciser si l’intervention nécessite une action de notre part ou un redémarrage.
Les éléments à obtenir par écrit
- La version ou le paquet PHP actuellement servi pour le site.
- La confirmation que le correctif correspondant est bien installé, y compris si l’hébergeur utilise des paquets adaptés à sa distribution.
- La date de déploiement, ou le calendrier annoncé si l’intervention n’est pas terminée.
- Les éventuelles actions requises de votre côté, ainsi que leur impact possible.
- La portée de la réponse : site concerné, autres domaines et éventuels environnements de test.
Le projet PHP signale que les distributions Linux et certains fournisseurs LTS peuvent intégrer les correctifs dans leurs propres paquets. Il faut donc demander à l’hébergeur de confirmer le correctif appliqué, plutôt que d’exiger uniquement un numéro de version amont précis. Le point essentiel est de savoir si le système qui traite les requêtes est corrigé. ([php.net](https://www.php.net/archive/2026.php))
Planifier une montée de version compatible
Corriger d’abord, moderniser ensuite
Si votre hébergement utilise une version concernée, demandez rapidement une mise à jour corrective. Les branches concernées par l’avis du 21 octobre disposent de versions corrigées listées par le projet PHP. PHP 8.2 atteint par ailleurs la fin de vie le 31 décembre 2026 selon l’annonce PHP : si votre environnement est encore sur cette branche, ne confondez pas le correctif immédiat avec un plan durable. Organisez avec l’hébergeur une migration vers une version maintenue et adaptée à vos applications. ([php.net](https://www.php.net/archive/2026.php))
Attention toutefois : une montée de version majeure ou un changement de branche peut révéler des incompatibilités dans un thème, une extension, une boutique ou un développement sur mesure. Il ne s’agit pas de repousser un correctif de sécurité, mais d’organiser le changement de façon maîtrisée avec le fournisseur ou votre prestataire technique.
Avant le changement
- Demandez quelle version cible est proposée et si elle est maintenue.
- Vérifiez que votre version de WordPress, vos extensions et votre thème sont compatibles avec cette version de PHP.
- Identifiez les composants essentiels : formulaires, paiement, réservation, espace client, synchronisations et tâches automatisées.
- Confirmez qu’une sauvegarde récente des fichiers et de la base de données est disponible et restaurable.
- Demandez si une préproduction ou un créneau de test est possible avant le basculement du site public.
Après le changement
Ne vous limitez pas à ouvrir la page d’accueil. Effectuez les parcours qui comptent pour l’activité : envoyer un formulaire, se connecter, rechercher un produit, ajouter au panier, finaliser une commande ou consulter une page protégée. Contrôlez également les courriels automatiques et les connexions avec les outils externes. Notez les erreurs, l’heure du test et les pages touchées afin que le support puisse intervenir efficacement.
Si une fonction essentielle ne marche plus, transmettez des éléments concrets à l’hébergeur ou au développeur. Le retour à une ancienne version vulnérable ne devrait pas être la réponse automatique : demandez plutôt un diagnostic et une solution compatible, tout en convenant de la manière de maintenir le correctif de sécurité.
Prioriser les actions et garder une trace
Pour une PME, la gestion de l’incident peut tenir dans un suivi simple. Attribuez un responsable, consignez la réponse du support et gardez une preuve de la version corrigée ou de la migration. Si le site héberge une boutique ou traite des demandes commerciales, prévoyez une vérification fonctionnelle après intervention et informez les personnes qui dépendent du site.
À faire aujourd’hui :
- Relever la version PHP utilisée par chaque site concerné.
- Ouvrir un ticket à l’hébergeur si la version ou le statut du correctif n’est pas clair.
- Demander une confirmation écrite du correctif pour l’environnement qui sert les requêtes web.
- Si une évolution de version est nécessaire, convenir d’un plan de compatibilité, de sauvegarde et de tests.
- Ajouter le contrôle PHP à votre inventaire technique et à votre routine de maintenance.
Les mesures temporaires ne remplacent pas une mise à jour : le projet PHP précise que seule la mise à jour constitue une solution complète. En cas d’impossibilité de corriger immédiatement, demandez à l’hébergeur quelles mesures il applique et quel est le délai de correction. N’improvisez pas des réglages serveur sans comprendre leur portée. ([php.net](https://www.php.net/archive/2026.php))
Encadré pratique — votre contrôle est terminé lorsque vous pouvez répondre oui à ces quatre questions : connaissez-vous la version PHP réellement utilisée ? L’hébergeur a-t-il confirmé par écrit le correctif ? Une version maintenue est-elle prévue si votre branche approche de sa fin de support ? Les fonctions essentielles du site ont-elles été testées après changement ? Si une réponse manque, ouvrez ou relancez un ticket et conservez la réponse dans votre dossier technique.
Pour inscrire cette vérification dans un suivi plus large, consultez notre article sur l’inventaire technique PHP et Node.js. Si une intervention sur votre site est nécessaire, découvrez aussi notre service de création et d’accompagnement web, ou contactez Enovatic pour faire le point sur votre situation.
Questions fréquentes
Une mise à jour WordPress corrige-t-elle cette faille PHP ?
Non. L’alerte porte sur PHP, le moteur utilisé par le serveur pour exécuter des applications. WordPress.org précise qu’aucune mise à jour WordPress n’est requise ou prévue pour corriger ces vulnérabilités. Il faut vérifier la version et le correctif PHP auprès de l’hébergeur. ([wordpress.org](https://wordpress.org/news/2026/10/critical-php-security-release/))
Comment voir la version PHP d’un site WordPress ?
Dans l’administration, consultez Outils > Santé du site > Informations > Serveur. Vous pouvez aussi vérifier le panneau de l’hébergeur. En cas de différence ou d’incertitude, demandez au support de confirmer la version qui traite les requêtes du domaine concerné.
Mon hébergeur dit avoir appliqué un correctif, mais la version affichée n’a pas changé. Que faire ?
Demandez le détail du paquet ou du correctif appliqué et sa portée. Les distributions et fournisseurs LTS peuvent intégrer des correctifs sans présenter exactement le même numéro de version amont. L’hébergeur doit confirmer que l’environnement qui sert votre site est bien corrigé. ([php.net](https://www.php.net/archive/2026.php))
Faut-il changer immédiatement de version PHP ?
Il faut faire corriger rapidement l’environnement concerné, mais la méthode dépend de l’hébergement et de la compatibilité de l’application. Faites confirmer le correctif disponible, puis planifiez tout changement de branche avec sauvegarde et tests. Une migration durable doit aussi tenir compte du cycle de support de la version choisie.
Cette alerte concerne-t-elle uniquement les sites WordPress ?
Non. Elle concerne les installations PHP qui servent des requêtes web et peut toucher toute application PHP exposée sur le serveur. Les boutiques et autres outils hébergés en PHP doivent donc également être inventoriés et vérifiés. ([php.net](https://www.php.net/archive/2026.php))
Conclusion : vérifiez le serveur, puis documentez la correction
L’alerte du 21 octobre rappelle qu’un site WordPress dépend d’une pile technique plus large que son tableau de bord. Pour agir efficacement, identifiez la version PHP réellement utilisée, demandez à l’hébergeur une confirmation précise du correctif et préparez une montée de version compatible si nécessaire. Conservez les réponses, les dates et les résultats des tests : ce suivi transforme une alerte ponctuelle en amélioration concrète de votre maintenance.
Vous ne savez pas quelle version exécute votre site ou comment organiser les tests ? Parlez-en à l’équipe Enovatic pour clarifier les prochaines étapes et sécuriser la gestion technique de votre présence en ligne.
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 : Winston Chen sur Unsplash.
