Maintenance & accompagnement

WordPress et la faille PHP du 21 octobre 2026 : vérifier votre version et protéger votre site

Toutes les installations WordPress sont concernées par la faille PHP du 21 octobre 2026. Voici comment vérifier en deux minutes et agir selon votre hébergement.

WordPress et la faille PHP du 21 octobre 2026 : vérifier votre version et protéger votre site

WordPress est écrit en PHP, et chaque page de votre site passe par le moteur PHP de votre hébergeur. La faille PHP du 21 octobre 2026 (CVE-2026-109618 et CVE-2026-109619, voir notre explication complète) concerne donc tous les sites WordPress, du blog personnel à la boutique WooCommerce, quel que soit le thème, les plugins ou le niveau de mise à jour de WordPress lui-même. La bonne nouvelle : pour la majorité des sites, c'est l'hébergeur qui corrige. La mauvaise : il faut vérifier qu'il l'a fait, et beaucoup de sites tournent encore sur une version de PHP qui n'aura jamais de correctif.

Pourquoi mettre à jour WordPress ne suffit pas

Il y a une confusion fréquente entre mettre à jour WordPress (le CMS, ses thèmes et ses plugins) et mettre à jour PHP (le langage qui exécute WordPress). La faille du 21 octobre est dans PHP. Un site WordPress parfaitement à jour, avec tous ses plugins au dernier numéro, reste vulnérable si le serveur exécute PHP 8.4.26 ou 8.1.x. Et comme la faille peut, sur Apache avec mod_php, être déclenchée avant même que WordPress se charge, aucun plugin de sécurité ne peut l'intercepter à lui seul.

Vérifier votre version de PHP en deux minutes

  1. Connectez-vous à l'administration de WordPress.
  2. Allez dans Outils, puis Santé du site, onglet Informations.
  3. Ouvrez la section Serveur : la ligne « Version de PHP » indique la version exacte.
  4. Comparez avec les versions corrigées : 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.

Deux précisions. D'abord, si la version affichée est 8.1.x, 8.0.x ou 7.4.x, votre site est sur une branche sans correctif : il faut changer de version, pas attendre. Ensuite, sur certains hébergements basés sur Debian ou Ubuntu, le correctif peut être appliqué sans que le numéro de version change. Dans le doute, demandez à votre hébergeur s'il a déployé la publication du 21 octobre 2026.

Selon votre hébergement

Hébergement WordPress infogéré

Les offres WordPress clés en main mettent PHP à jour sur l'ensemble de leurs serveurs. Consultez leur page de statut ou votre boîte mail, et contactez le support si vous n'avez aucune information en fin de journée. Vérifiez aussi que votre site n'est pas resté sur une vieille branche par choix (certains panneaux laissent le client sélectionner la version).

Hébergement mutualisé (cPanel, Plesk ou panneau maison)

L'hébergeur déploie le correctif pour tous les comptes du serveur. De votre côté, ouvrez le gestionnaire de versions PHP du panneau (« Sélectionner une version PHP », « MultiPHP Manager » ou équivalent) et assurez-vous que votre domaine utilise une branche supportée. Si le panneau propose encore 7.4 ou 8.1 par défaut, passez en 8.3 ou 8.4 après le test décrit plus bas.

VPS ou serveur dédié

Personne ne mettra PHP à jour à votre place. L'administrateur doit installer les paquets corrigés et redémarrer PHP-FPM ou Apache pour que chaque processus utilise la version corrigée. La procédure détaillée par système est dans mettre à jour PHP sur votre serveur. C'est la catégorie de sites qui doit agir aujourd'hui.

Changer de branche PHP sans casser le site

Passer de 8.1 à 8.4 est plus qu'une mise à jour de sécurité : certaines fonctions ont été dépréciées ou retirées, et un vieux thème ou un plugin abandonné peut provoquer une erreur fatale. Sur une boutique, une page de paiement cassée coûte de l'argent dès la première heure. La méthode qui évite les mauvaises surprises :

  1. Sauvegarde complète avant tout changement (fichiers et base de données).
  2. Inventaire des plugins et du thème : notez ceux qui n'ont pas été mis à jour depuis plus d'un an. Ce sont les candidats aux problèmes.
  3. Test sur une copie de préproduction (staging) : la plupart des hébergeurs en proposent une en un clic. Basculez la copie sur la nouvelle version de PHP et parcourez tout le site.
  4. Vérification des parcours clés : pages principales, formulaires, recherche, compte client, panier et paiement, envoi d'emails.
  5. Bascule de la production, idéalement à une heure creuse, puis nouvelle vérification.
  6. Surveillance des journaux d'erreurs pendant 48 heures.

Si l'hébergeur impose la mise à jour sans préavis, faites au moins la sauvegarde et la vérification après coup. Et si un plugin bloque la montée de version, cherchez une alternative maintenue plutôt que de rester sur une branche PHP vulnérable. Notre guide mettre à jour WordPress sans risque décrit le même cycle pour le CMS.

Les couches de protection supplémentaires

  • Cloudflare ou un autre WAF : sur l'offre gratuite de Cloudflare, les règles de pare-feu gérées sont actives par défaut ; sur les offres payantes, vérifiez que les règles sont en mode « bloquer » et pas seulement « journaliser ». Un attaquant peut parfois contourner le proxy en visant directement l'adresse du serveur : c'est une couche, pas un correctif.
  • Désactiver `session.upload_progress` côté serveur (WordPress n'utilise pas cette fonctionnalité) ferme l'un des chemins d'attaque confirmés de la CVE-2026-109619. Sur un mutualisé, demandez-le à l'hébergeur plutôt que de modifier la configuration vous-même.
  • Un plugin de sécurité ne corrige pas une faille du moteur PHP. Il reste utile pour détecter des fichiers modifiés après coup.

Que surveiller dans les prochains jours

Même avec un site corrigé, gardez un œil sur les signes d'une compromission survenue avant la mise à jour : fichiers PHP inconnus dans wp-content/uploads, utilisateurs administrateurs que vous n'avez pas créés, redirections vers des sites étrangers, pics de charge inexpliqués, emails de spam envoyés depuis votre domaine. Si vous repérez l'un de ces signes, suivez notre guide d'urgence pour un site WordPress piraté.

Faire suivre votre WordPress par une équipe

Vérifier une version de PHP prend deux minutes. Le faire pour chaque alerte, sur chaque site, avec un test de préproduction et une sauvegarde à chaque fois, c'est un travail régulier. C'est le cœur de notre offre de maintenance et accompagnement : nous connaissons la version de PHP de chaque site que nous suivons, et une alerte comme celle du 21 octobre déclenche une vérification de tous les sites dans la journée. Parlons de votre site si vous souhaitez qu'il en fasse partie.

Questions fréquentes

Mon plugin de sécurité WordPress me protège-t-il de cette faille ?

Non. La faille est dans PHP, en dessous de WordPress. Sur Apache avec mod_php, elle peut être déclenchée avant que WordPress et ses plugins se chargent. Seule la mise à jour de PHP corrige le problème.

Quelle version de PHP choisir pour WordPress en 2026 ?

PHP 8.3 ou 8.4, toutes deux supportées par WordPress et par la majorité des plugins maintenus. Évitez 8.2, dont le support de sécurité s'arrête le 31 décembre 2026, et abandonnez 8.1 et plus ancien.

WooCommerce fonctionne-t-il sur PHP 8.4 ?

Les versions récentes de WooCommerce supportent PHP 8.4. Le risque vient plutôt des extensions tierces (passerelles de paiement, modules de livraison) peu maintenues. Testez sur une copie de préproduction avant de basculer la boutique.

Comment savoir si mon hébergeur a appliqué le correctif ?

Regardez la version affichée dans Santé du site. Si elle n'a pas changé mais que l'hébergeur affirme avoir corrigé (cas des rétroportages Debian ou Ubuntu), demandez-lui une confirmation écrite mentionnant les CVE-2026-109618 et CVE-2026-109619.