Alerte de sécurité PHP : votre site WordPress est-il à jour?
Le directeur d’une entreprise de rénovation de Québec se connecte à son tableau de bord WordPress une fois par mois. Aucune bannière rouge, aucune notification urgente : il en conclut que son site est à jour.
Ce qu’il ignore, c’est que WordPress ne fonctionne pas seul. Il repose sur PHP, un langage installé sur le serveur et géré séparément, souvent par l’hébergeur. Le 21 octobre 2026, ce langage a fait l’objet d’une alerte de sécurité critique.
Pas besoin de paniquer, mais cette alerte rappelle qu’un site WordPress à jour ne se résume pas à un tableau de bord sans notification. Voici ce qui s’est passé et ce que vous devez vérifier.
Ce qu’il faut retenir
- Le 21 octobre 2026, le projet PHP a corrigé deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, évaluées à 9,2 sur 10.
- Ces failles touchent PHP, pas WordPress : aucune mise à jour de WordPress n’est requise pour les corriger.
- La mise à jour de PHP relève généralement de l’hébergeur, mais c’est à vous de confirmer qu’elle a été faite.
- WordPress recommande PHP 8.3 ou une version plus récente. PHP 8.2 cessera de recevoir des correctifs de sécurité le 31 décembre 2026.
- Une maintenance sérieuse couvre WordPress, les extensions, le thème, le serveur, les sauvegardes et le certificat SSL.
Que s’est-il passé avec PHP en octobre 2026?
Le 21 octobre 2026, le projet PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Selon l’avis de sécurité publié sur PHP.net, ces versions corrigent deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619. Elles sont toutes deux évaluées à 9,2 sur 10 selon l’échelle CVSS v4.0.
Concrètement, ces failles peuvent permettre à une personne malveillante d’exécuter du code à distance sur un serveur, sans avoir besoin de s’y connecter. L’avis précise que les installations PHP qui répondent à des requêtes web sont concernées et que la mise à jour est la seule correction complète.
Pourquoi cette alerte concerne les sites WordPress
WordPress est écrit en PHP. Chaque fois qu’un visiteur ouvre une page, c’est PHP qui exécute le code de WordPress, du thème et des extensions sur le serveur. Si PHP présente une faille, tout ce qui repose sur lui peut être exposé.
C’est pourquoi WordPress a publié sa propre alerte de sécurité PHP le jour même. L’équipe encourage les propriétaires de sites à mettre à jour PHP immédiatement ou à vérifier auprès de leur hébergeur que les correctifs ont été appliqués.
Cette vulnérabilité vient-elle de WordPress ou de PHP?
Elle vient de PHP. WordPress le précise clairement : aucune mise à jour de WordPress n’est requise ni prévue pour corriger ces failles.
Les vulnérabilités concernent les serveurs qui hébergent une application PHP, qu’il s’agisse de WordPress, d’une boutique en ligne ou d’une application sur mesure.
Mettre à jour WordPress, les extensions et le thème demeure nécessaire. Cela ne corrigera toutefois pas une faille située dans PHP : le correctif doit être appliqué sur le serveur.
Comment savoir quelle version de PHP votre site utilise
La vérification prend moins d’une minute. Dans le tableau de bord WordPress, ouvrez Outils > Santé du site > Informations, puis déployez la section Serveur. La version de PHP y est indiquée. Plusieurs hébergeurs affichent aussi cette information dans leur panneau de contrôle.
Notez le numéro complet. Les versions officielles corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
Certains hébergeurs et fournisseurs Linux peuvent toutefois intégrer les correctifs à leurs propres versions sans que le numéro affiché corresponde exactement à celui publié par PHP. Dans le doute, demandez à votre hébergeur de confirmer que les correctifs liés aux CVE-2026-109618 et CVE-2026-109619 ont été appliqués.
Quelles versions de PHP sont encore prises en charge?
Selon la page officielle des versions prises en charge, quatre branches reçoivent encore des correctifs à la fin d’octobre 2026 :
- PHP 8.5 : soutien actif jusqu’au 31 décembre 2027 et correctifs de sécurité jusqu’au 31 décembre 2029.
- PHP 8.4 : soutien actif jusqu’au 31 décembre 2026 et correctifs de sécurité jusqu’au 31 décembre 2028.
- PHP 8.3 : correctifs de sécurité seulement, jusqu’au 31 décembre 2027.
- PHP 8.2 : correctifs de sécurité seulement, jusqu’au 31 décembre 2026.
Les versions antérieures à PHP 8.2 ne reçoivent déjà plus de mises à jour de sécurité officielles du projet PHP. Certains fournisseurs peuvent offrir des correctifs prolongés, mais cela doit être confirmé auprès de l’hébergeur.
Du côté de WordPress, les exigences techniques officielles recommandent PHP 8.3 ou une version plus récente.
Pourquoi la fin de vie de PHP 8.2 est importante
Le 31 décembre 2026, PHP 8.2 atteindra sa fin de vie. Après cette date, si une nouvelle faille est découverte dans cette version, elle ne sera plus corrigée officiellement par le projet PHP.
Utiliser une version non prise en charge ne signifie pas automatiquement que votre site a été piraté. Cela signifie plutôt que votre exposition augmente avec le temps, puisque les nouvelles vulnérabilités découvertes pourraient rester ouvertes.
Si votre site utilise encore PHP 8.2, planifiez dès maintenant le passage à PHP 8.3 ou à une version plus récente.
Mettre à jour PHP suffit-il pour sécuriser WordPress?
Non. La mise à jour de PHP corrige les failles du langage, mais la sécurité d’un site repose sur plusieurs couches :
- le cœur de WordPress;
- les extensions;
- le thème;
- la configuration du serveur;
- les sauvegardes;
- les comptes et les accès des utilisateurs.
Une extension abandonnée peut créer un risque, même sur un serveur parfaitement à jour.
Changer de version de PHP comporte également un risque de compatibilité. Un thème ancien ou une extension mal entretenue peut cesser de fonctionner avec une version récente.
La page de compatibilité entre WordPress et PHP indique quelles versions de PHP sont prises en charge par WordPress. Elle ne garantit toutefois pas la compatibilité de chaque extension et de chaque thème.
Les éléments à vérifier avant une mise à jour PHP
Sauvegarder le site et la base de données
Avant toute intervention, assurez-vous d’avoir une sauvegarde complète des fichiers et de la base de données.
Une sauvegarde n’a de valeur que si elle peut être restaurée. Testez la restauration, plutôt que de simplement supposer que votre système fonctionne.
Vérifier la compatibilité du thème et des extensions
Mettez d’abord à jour WordPress, les extensions et le thème. Confirmez ensuite que les extensions importantes sont compatibles avec la version de PHP visée.
Portez une attention particulière aux extensions qui gèrent :
- les formulaires;
- les paiements;
- les réservations;
- les comptes clients;
- les connexions avec un CRM;
- le commerce électronique.
Une extension qui n’a pas reçu de mise à jour depuis plusieurs années constitue un signal d’alerte.
Tester la mise à jour dans un environnement de préproduction
Un environnement de préproduction est une copie du site qui n’est pas accessible au public. Il permet de tester les changements sans risquer d’interrompre le site en ligne.
Plusieurs hébergeurs permettent d’en créer un en quelques clics. Changez la version de PHP sur cette copie, puis vérifiez les pages principales, les formulaires, les connexions et le processus d’achat avant de modifier le site public.
Surveiller le site après la mise à jour
Après la mise à jour, consultez les journaux d’erreurs du serveur. Soumettez un formulaire de test et vérifiez toutes les fonctions critiques.
Un problème de compatibilité peut toucher un formulaire de soumission et vous faire perdre des demandes sans qu’une erreur soit immédiatement visible.
Tableau des responsabilités : entreprise, agence et hébergeur
Une grande source de risque est le flou entourant les responsabilités. Chacun croit que l’autre s’occupe de la maintenance.
| Élément | Qui le met à jour? | Risque principal | Fréquence de vérification |
|---|---|---|---|
| WordPress | Agence, équipe web ou administrateur | Failles du système principal | Dès qu’une mise à jour de sécurité paraît |
| Extensions | Agence ou administrateur | Vulnérabilité ou incompatibilité | Chaque semaine |
| Thème | Agence ou développeur | Faille ou bris d’affichage | Chaque mois et avant une mise à jour majeure |
| PHP | Hébergeur ou administrateur du serveur | Failles du serveur et incompatibilités | À chaque avis de sécurité |
| Sauvegardes | Hébergeur et responsable du site | Perte de données ou restauration impossible | Vérification mensuelle |
| Certificat SSL | Hébergeur | Avertissement de sécurité et perte de confiance | Surveillance automatique |
Si vous gérez vous-même votre serveur, la responsabilité de PHP vous revient.
WordPress recommande même d’envisager de mettre le serveur hors ligne lorsqu’il fonctionne avec une version antérieure à PHP 8.2 et qu’aucune correction immédiate ne peut être appliquée.
Les risques d’un site WordPress mal entretenu
Un site négligé ne pose pas seulement un risque de sécurité.
- Interruption de service : une incompatibilité peut afficher une page d’erreur ou bloquer les formulaires.
- Perte de confiance : un avertissement de sécurité dans le navigateur peut faire fuir les visiteurs.
- Recul dans les résultats de recherche : un site piraté, lent ou instable peut nuire à votre référencement organique.
- Perte de demandes : un formulaire défectueux peut cesser de transmettre les messages sans produire d’erreur visible.
- Coûts imprévus : réparer un site compromis coûte généralement plus cher qu’un entretien régulier.
- Perte de données : une sauvegarde inutilisable peut empêcher de restaurer rapidement le site.
Un serveur correctement entretenu contribue aussi à la performance du site, un enjeu expliqué dans notre article sur le coût caché d’un site web lent.
À quoi devrait servir un contrat de maintenance WordPress?
Un bon contrat de maintenance ne se limite pas à cliquer sur « Mettre à jour les extensions ».
Il devrait préciser :
- qui surveille les avis de sécurité de WordPress, des extensions et de PHP;
- qui communique avec l’hébergeur;
- qui confirme l’application des correctifs du serveur;
- la fréquence des sauvegardes;
- la fréquence des tests de restauration;
- la procédure utilisée avant une mise à jour importante;
- le délai d’intervention en cas de problème;
- les fonctions du site qui doivent être testées;
- la façon dont chaque intervention est documentée.
Si votre site repose sur un thème ancien ou sur des extensions abandonnées, la maintenance peut atteindre ses limites. Notre article sur la refonte de site web vous aidera à déterminer s’il vaut mieux continuer à corriger le site ou reconstruire sur des bases plus solides.
Checklist de maintenance WordPress et PHP
Avant toute mise à jour importante, suivez ces étapes dans l’ordre :
- Confirmer la version actuelle de PHP.
- Vérifier que les sauvegardes sont récentes et restaurables.
- Mettre à jour WordPress, les extensions et le thème.
- Vérifier la compatibilité avec la nouvelle version de PHP.
- Créer un environnement de préproduction.
- Tester les formulaires, les paiements et les connexions.
- Effectuer la mise à jour de PHP.
- Vérifier les journaux d’erreurs et les fonctions importantes.
- Confirmer que les sauvegardes automatiques fonctionnent toujours.
- Documenter la date et la personne responsable de l’intervention.
Que faire maintenant?
Cette semaine, ouvrez Outils > Santé du site > Informations > Serveur et notez votre version de PHP.
Écrivez ensuite à votre hébergeur pour lui demander si les correctifs du 21 octobre 2026 ont été appliqués.
Si votre site utilise PHP 8.2 ou une version plus ancienne, planifiez une migration vers PHP 8.3 ou une version plus récente avant la fin de l’année.
Enfin, confirmez qui est responsable de chaque élément présenté dans le tableau ci-dessus. Un site devient vulnérable lorsque tout le monde suppose que quelqu’un d’autre s’en occupe.
FAQ
Dans le tableau de bord WordPress, allez dans Outils > Santé du site > Informations, puis ouvrez la section Serveur. La version de PHP y est affichée. Votre hébergeur peut aussi vous la confirmer.
Oui. Un problème peut survenir si le thème ou certaines extensions ne sont pas compatibles avec la nouvelle version. Il faut donc sauvegarder le site, mettre ses composants à jour et tester le changement dans un environnement de préproduction avant de l’appliquer au site public.
PHP est généralement mis à jour par l’hébergeur ou l’administrateur du serveur. Si vous gérez votre propre serveur, cette responsabilité vous revient. Dans tous les cas, le propriétaire du site doit confirmer que les correctifs ont été appliqués.
PHP 8.2 atteindra sa fin de vie le 31 décembre 2026. À partir de 2027, il ne recevra plus de correctifs de sécurité officiels du projet PHP. Le site pourra continuer de fonctionner, mais toute nouvelle faille découverte pourrait rester ouverte.
Selon ses exigences techniques officielles, WordPress recommande PHP 8.3 ou une version plus récente, avec MySQL 8.0 ou MariaDB 10.11 ou une version plus récente.
Des versions plus anciennes peuvent encore faire fonctionner WordPress, mais elles peuvent présenter des risques supplémentaires de sécurité et de compatibilité.
Les extensions devraient être vérifiées chaque semaine, le thème chaque mois et les sauvegardes testées au moins une fois par mois. Les mises à jour de sécurité de WordPress et de PHP doivent être traitées dès leur publication plutôt que selon un calendrier fixe.
