Faille PHP WordPress : vérifiez la version PHP de votre site

Vous avez mis à jour WordPress, vos extensions et votre thème. Cette fois, cela ne suffit pas. Le 21 octobre 2026, le projet PHP a publié en urgence les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent deux failles critiques qui permettent à un attaquant d'exécuter du code sur un serveur sans s'identifier (PHP.net). Cette faille PHP touche WordPress sans venir de WordPress : elle se trouve dans PHP, le langage qui fait tourner votre site.

WordPress.org l'a confirmé le jour même : aucune mise à jour de WordPress n'est nécessaire ni prévue pour ces problèmes (WordPress.org). Pour la faille corrigée par WordPress 7.1.3, un clic sur « Mettre à jour » réglait l'essentiel. Ici, seule la mise à jour de PHP corrige le problème, et elle se fait du côté de votre hébergement. Voici comment vérifier où en est votre site, en trois étapes, puis quoi surveiller si une attaque a pu passer avant la correction.

Faille PHP WordPress : ce qui s'est passé du 17 au 21 octobre

Les deux failles portent les références CVE-2026-109618 et CVE-2026-109619. Elles sont notées 9.2 sur 10 sur l'échelle de gravité CVSS (Codeable). Elles se logent dans la gestion de la mémoire et des erreurs, des parties de PHP sollicitées par presque chaque visite (The PHP Foundation).

Le calendrier a dérapé. Le 20 octobre vers 15 h, heure d'Abidjan, les références des failles ont commencé à circuler sur des forums et des réseaux sociaux. Le projet PHP a alors avancé la publication d'un jour, au 21 octobre à 14 h (The PHP Foundation).

Les attaques n'ont pas attendu. De premières attaques ont été repérées dès 7 h 43 le 21 octobre, avant même la sortie du correctif (Sansec). Cloudflare filtre le trafic d'une grande partie des sites web. Selon son patron, les tentatives se comptaient par milliers avant l'annonce, par centaines de milliers deux heures après, puis par millions le lendemain (Codeable). Amazon dit même avoir repéré une tentative dès le 17 octobre (Cybernews).

Un bémol utile. D'après Sansec, société spécialisée dans la sécurité des boutiques en ligne, les exploits publics testés ne fonctionnent pas sur une installation PHP par défaut : la plupart ont besoin d'une autre faille dans le site visé (Sansec). Pas de quoi paniquer, donc. Mais de quoi vérifier cette semaine.

Étape 1 : trouver la version PHP de votre site WordPress

Deux chemins possibles.

• Dans le tableau de bord WordPress : menu Outils, puis Santé du site, onglet Infos, rubrique Serveur. La version de PHP y figure (WordPress.org).
• Dans l'espace client de votre hébergeur : la plupart des panneaux d'administration l'affichent aussi (WordPress.org).

Notez le numéro complet, avec ses trois chiffres. Si vous n'avez accès ni au tableau de bord ni à l'hébergement, c'est déjà une information : un prestataire ou un ancien développeur détient les clés. Récupérez-les avant toute autre chose.

Étape 2 : vérifier que le correctif PHP est bien appliqué

Comparez votre numéro aux versions corrigées publiées par PHP (PHP.net) :

• PHP 8.5 : 8.5.12 ou plus ;
• PHP 8.4 : 8.4.27 ou plus ;
• PHP 8.3 : 8.3.36 ou plus ;
• PHP 8.2 : 8.2.35 ou plus.

Votre numéro est plus ancien ? Ne concluez pas trop vite. Beaucoup d'hébergeurs utilisent des versions de PHP fournies par des éditeurs comme CloudLinux ou cPanel, qui ont intégré le correctif sans changer le numéro affiché. Un serveur protégé peut donc indiquer 8.3.35 au lieu de 8.3.36 (InMotion Hosting).

Pour en avoir le cœur net, posez la question par écrit à votre hébergeur : « Avez-vous appliqué sur mon serveur le correctif de sécurité PHP du 21 octobre 2026 ? » (Codeable). Gardez sa réponse.

Qui doit agir dépend de votre formule d'hébergement (Codeable) :

• Hébergement WordPress infogéré : l'hébergeur met PHP à jour sur ses serveurs. Demandez une confirmation si vous n'avez rien reçu.
• Hébergement mutualisé, la formule classique avec cPanel ou un panneau équivalent : l'hébergeur déploie la version corrigée pour tous ses clients. Guettez son message, relancez-le au besoin.
• Serveur privé (VPS) ou serveur que vous gérez vous-même : personne ne le fera à votre place. Celui qui administre ce serveur doit installer les paquets PHP corrigés et redémarrer PHP. C'est le cas le plus urgent.

Si vous ne savez pas dans quelle case vous êtes, notre guide pour choisir un hébergement WordPress explique les différences entre ces formules.

Si votre site passe par Cloudflare, des règles de pare-feu contre ces attaques sont actives sur toutes les offres, y compris la gratuite (Codeable). C'est une couche de protection, pas un correctif : Cloudflare demande lui-même de mettre PHP à jour (Codeable).

Dernier point technique. Le 23 octobre, PHP a conseillé de garder désactivée l'option de suivi de progression des envois de fichiers jusqu'à sa prochaine mise à jour régulière (PHP.net). WordPress n'utilise pas cette fonction (InMotion Hosting). Sur un hébergement mutualisé, ne touchez pas vous-même aux réglages du serveur : demandez à l'hébergeur (Codeable).

Étape 3 : migrer si votre site tourne sur une version PHP abandonnée

Le projet PHP ne publie plus de correctifs pour PHP 8.1 et les versions antérieures (PHP.net). Certains éditeurs ont tout de même corrigé d'anciennes versions : cPanel pour PHP 7.4, 8.0 et 8.1, CloudLinux pour toutes les versions de son sélecteur PHP. En revanche, PHP 7.3 et plus ancien sur un serveur cPanel sans CloudLinux ne recevra aucun correctif (InMotion Hosting).

Même rafistolée, une vieille version reste un sursis. La vraie sortie consiste à passer à une version suivie (Codeable). Et visez juste : PHP 8.2 ne recevra plus de correctifs de sécurité après le 31 décembre 2026 (PHP.net). Mieux vaut donc migrer directement vers PHP 8.3 ou une version plus récente (InMotion Hosting).

Le changement se fait souvent en quelques clics dans le panneau d'hébergement. Le risque est ailleurs : un vieux thème ou une vieille extension peut cesser de fonctionner avec une version récente de PHP (Codeable). Sur une boutique en ligne, un panier qui plante, ce sont des ventes perdues le jour même. Procédez dans l'ordre (Codeable) :

1. Faites une sauvegarde complète du site, fichiers et base de données.
2. Testez la nouvelle version de PHP sur une copie du site, dite « de préproduction ».
3. Corrigez ce qui casse : extension à remplacer, thème à mettre à jour.
4. Basculez le site en ligne, puis vérifiez aussitôt les pages clés, les formulaires et le paiement.

Si vous gérez vous-même votre serveur, qu'il tourne sous une version antérieure à 8.2 et que la migration ne peut pas se faire tout de suite, WordPress.org et le Centre national de cybersécurité britannique conseillent d'envisager de mettre le site hors ligne le temps de migrer (WordPress.org).

Ce qu'il faut surveiller si une attaque est passée avant la correction

Mettre PHP à jour ferme la porte. Cela ne fait pas sortir quelqu'un qui serait déjà entré. Amazon recommande d'examiner toute activité suspecte depuis le 17 octobre, sans supposer que les attaques ont commencé avec l'annonce publique (Cybernews).

Dans les jours qui viennent, vérifiez ou faites vérifier :

• la liste des utilisateurs WordPress : un compte administrateur que personne ne reconnaît est un signal d'alarme ;
• les fichiers modifiés récemment, surtout des fichiers PHP dans le dossier des médias (wp-content/uploads), qui ne devrait contenir que des images et des documents ;
• le comportement du site : redirections vers d'autres adresses, pages inconnues dans les résultats Google, lenteurs soudaines ;
• les messages de votre hébergeur ou de Google signalant un contenu suspect ou une activité anormale.

Au moindre doute, prévenez votre hébergeur et suivez la page d'aide de WordPress.org consacrée aux sites piratés (WordPress.org). Si vous restaurez une sauvegarde, choisissez-en une antérieure au 17 octobre, et seulement après la mise à jour de PHP : sinon, la même porte reste ouverte.

Ce que vous pouvez faire cette semaine

Ouvrez Santé du site, notez votre version de PHP et envoyez la question à votre hébergeur dès aujourd'hui. Si vous êtes encore sous PHP 8.1 ou plus ancien, planifiez la migration vers PHP 8.3 avec une sauvegarde et un test préalable.

Si vous ne savez pas qui gère votre serveur, ou si la migration vous inquiète, notre équipe sécurité et maintenance WordPress peut commencer par l'audit de départ offert, puis s'occuper de la mise à jour et des contrôles.

Questions fréquentes

Mon site est sous la dernière version de WordPress. Suis-je protégé contre cette faille PHP ?

Non, pas forcément. La faille se trouve dans PHP, le langage sur lequel tourne WordPress, et WordPress.org a confirmé qu'aucune mise à jour de WordPress ne la corrige. Seule une version de PHP corrigée, appliquée par votre hébergeur ou par l'administrateur de votre serveur, vous protège.

Mon hébergement affiche une version PHP plus ancienne que celles corrigées. Mon site est-il vulnérable ?

Pas nécessairement. Des éditeurs comme CloudLinux ou cPanel ont intégré le correctif dans leurs versions existantes sans changer le numéro affiché. La seule façon d'en être sûr est de demander par écrit à votre hébergeur s'il a appliqué le correctif de sécurité PHP du 21 octobre 2026.

Passer à PHP 8.3 peut-il casser mon site WordPress ?

C'est possible si votre thème ou certaines extensions sont anciens. Faites d'abord une sauvegarde complète, testez la nouvelle version sur une copie du site, corrigez ce qui ne fonctionne plus, puis basculez le site en ligne et vérifiez les formulaires et le paiement.

Cloudflare suffit-il à protéger mon site ?

Non. Cloudflare a activé des règles de pare-feu contre ces attaques sur toutes ses offres, y compris la gratuite, mais c'est une couche de protection, pas un correctif. Cloudflare demande lui-même de mettre PHP à jour.

Comment savoir si mon site a été piraté avant la correction ?

Contrôlez la liste des utilisateurs WordPress, cherchez des fichiers PHP dans le dossier des médias et surveillez les redirections ou les pages inconnues dans Google. Amazon recommande d'examiner l'activité depuis le 17 octobre. Au moindre doute, prévenez votre hébergeur et faites analyser le site.

Sources

• PHP.net, Security advisory: Critical remote code execution vulnerabilities, update now (et avis du 23 octobre) (21 octobre 2026)
• WordPress.org, Critical PHP Security Release (21 octobre 2026)
• Codeable, PHP Security Release on 21 October 2026: What WordPress Site Owners Need to Do (21 octobre 2026)
• Sansec, PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619) (21 octobre 2026)
• The PHP Foundation, Today's PHP Security Release, and How We're Strengthening PHP Security (21 octobre 2026)
• Cybernews, PHP2Shell exploit attempts hit millions, Amazon and Cloudflare warn
• InMotion Hosting, Critical PHP Security Release October 21, 2026: What InMotion Hosting Is Doing (21 octobre 2026)

Cet article vous a été utile ?

Pas vraiment Utile Très utile