Faille PHP d’octobre 2026 : votre site WordPress est-il vraiment corrigé ?

Réponse courte : deux failles critiques de PHP (CVE-2026-109618 et CVE-2026-109619, surnommées « PHP2Shell ») permettent à un attaquant d’exécuter son propre code sur votre serveur, sans mot de passe. Les correctifs officiels sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiés le 21 octobre 2026. Mettre à jour WordPress ne règle rien : c’est le moteur PHP de votre hébergeur qu’il faut corriger. Et le piège, que presque personne ne mentionne : le numéro de version affiché par votre site ne vous dit pas si le correctif est appliqué. On vous explique comment le savoir.

Ce qui s’est passé, dans l’ordre

• 17 octobre 2026 — Amazon Threat Intelligence observe une première tentative d’exploitation, quatre jours avant l’annonce publique.
• 20 octobre, 15 h UTC — l’embargo fuit. Les deux numéros de CVE circulent sur les réseaux sociaux avant la sortie des correctifs. Une note de 10,0 circule dans la fuite.
• 21 octobre, 14 h UTC — l’équipe de sécurité de PHP publie les correctifs et attribue aux deux failles une note officielle de 9,2 (CVSS v4.0), pas 10,0.
• 21 octobre, matin — Sansec rapporte des attaques en cours avant même la publication du correctif. Tenable parle ensuite d’exploitation large.

Les versions qui contiennent le correctif

Pourquoi certains sites risquent bien plus que d’autres

Toutes les installations qui servent des requêtes web sont concernées — PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Mais le niveau de risque n’est pas le même partout : selon l’équipe PHP, il est le plus élevé sur Apache avec mod_php, où une simple requête non authentifiée peut déclencher l’exécution de code avant même que le code de votre site ne démarre, avec les réglages par défaut. En PHP-FPM, l’exploitation démontrée passe par le code de l’application — c’est plus contraignant pour l’attaquant.

Autrement dit : un vieux site sur un serveur Apache auto-géré est la cible la plus simple. Mais « je suis sur LiteSpeed » n’est pas une réponse — c’est seulement un cran de difficulté en plus.

Le piège : votre numéro de version ne prouve rien

C’est la partie que vous ne lirez pas ailleurs, et on peut la démontrer sur notre propre hébergement.

Notre site est hébergé chez Hostinger, sur CloudLinux. Le 22 octobre, nous avons regardé les versions de PHP réellement installées sur le serveur :

Regardez bien. Les quatre branches affichent une version inférieure au correctif officiel, et les quatre ont été recompilées le 21 octobre — entre 10 h 48 et 13 h 31 UTC, donc avant la publication officielle de 14 h UTC.

Deux lectures sont possibles :

1. L’hébergeur a reçu le correctif sous embargo et l’a rétroporté dans ses propres paquets, sans changer le numéro de version. L’horaire des recompilations va dans ce sens, mais nous n’avons pas pu le confirmer : le journal des paquets n’est pas lisible depuis un compte d’hébergement mutualisé.
2. Ces versions précèdent simplement le correctif, et personne n’avait encore mis à jour 24 heures après sa sortie. C’est tout aussi plausible.

Le numéro de version ne permet pas de trancher. Les hébergeurs qui utilisent CloudLinux, cPanel, Plesk ou les paquets d’une distribution Linux rétroportent couramment les correctifs de sécurité en conservant le numéro de version d’origine. Un site qui affiche « PHP 8.2.34 » peut être parfaitement protégé — ou pas du tout. Les deux existent.

Conséquence pratique : la seule réponse fiable vient de votre hébergeur, et il faut lui poser la question correctement.

Comment vérifier votre site en trois étapes

Étape 1 — Lire votre version PHP

Dans WordPress : Tableau de bord → Outils → Santé du site → Informations → Serveur. La ligne « Version de PHP » vous donne ce que votre site utilise. Notez-la, mais souvenez-vous de la section précédente : ce chiffre est un indice, pas une preuve.

Étape 2 — Poser la bonne question à votre hébergeur

N’écrivez pas « est-ce que mon PHP est à jour ? » — on vous répondra oui. Écrivez ceci :

« Bonjour, concernant les vulnérabilités PHP CVE-2026-109618 et CVE-2026-109619 corrigées le 21 octobre 2026 : le correctif est-il appliqué sur le serveur qui héberge mon site ? Si vos paquets conservent un numéro de version inférieur aux versions officielles (8.5.12, 8.4.27, 8.3.36, 8.2.35), pouvez-vous confirmer que le correctif a été rétroporté, et à quelle date ? »

Une réponse claire règle la question. Une réponse floue est une réponse : insistez.

Étape 3 — Chercher des traces de compromission

L’exploitation a commencé avant la publication du correctif. Si votre site tournait sur une configuration vulnérable, le fait d’être corrigé aujourd’hui n’efface pas ce qui a pu se passer avant. Signes à examiner :

• des comptes administrateurs que vous ne reconnaissez pas (Utilisateurs → Tous les utilisateurs, trier par date d’inscription) ;
• des fichiers PHP modifiés ou créés depuis le 17 octobre, surtout dans wp-content/uploads/, où aucun fichier PHP n’a de raison d’exister ;
• des tâches planifiées inconnues (extensions de type WP Crontrol) ;
• des redirections qui n’apparaissent que pour les visiteurs venant de Google, ou du contenu invisible ajouté à vos pages ;
• une hausse inexpliquée de l’envoi de courriels depuis votre domaine.

Le problème de fond : les sites québécois tournent sur du PHP trop vieux

Nous avons voulu savoir à quoi ressemble le parc réel. Le 22 octobre 2026, nous avons relevé les en-têtes HTTP publics de 325 sites d’entreprises québécoises trouvés dans les résultats Google de recherches locales (plombier, dentiste, entrepreneur, comptable, garage, toiture… à Québec, Montréal, Laval, Longueuil, Sherbrooke, Gatineau, Trois-Rivières, Saguenay et Lévis).

Résultat :

• 92 % des sites n’annoncent pas leur version PHP — une bonne pratique, et c’est d’ailleurs ce que nous venons d’appliquer sur ce site.
• Parmi ceux qui l’annoncent, 15 sur 25 affichent une branche en fin de vie : PHP 5.6, 7.4, 8.0 ou 8.1. Aucune de ces branches ne reçoit de version officielle corrigée.
• Plusieurs tournent sur Apache, la configuration où l’exécution de code non authentifiée a été démontrée.
• Et le résultat le plus parlant : parmi les 25 sites qui affichent leur version, aucun n’est à un numéro égal ou supérieur aux versions officiellement corrigées. Ça ne veut pas dire que ces 25 sites sont vulnérables — ça veut dire que le numéro de version est un indicateur inutilisable pour le savoir, exactement comme sur notre propre serveur.
• Cinq de ces sites partagent la même empreinte — PHP 5.6.40 sur Apache 2.4.38 (Debian) — et répondent depuis trois adresses IP voisines du même bloc : la même infrastructure, probablement le même prestataire, abandonnée depuis des années. Quand un hébergement vieillit, il emporte tous ses sites avec lui.

Une nuance honnête sur ces chiffres : les sites qui exposent leur version PHP sont justement ceux dont la configuration est la plus ancienne. Ce n’est donc pas la proportion du parc québécois complet — c’est un échantillon biaisé vers le vieux. Mais ça reste révélateur : quand on peut voir, ce qu’on voit est presque toujours périmé.

PHP en fin de vie : l’échéance que personne ne regarde

C’est le vrai sujet, et il survivra à cette faille-ci. Pour PHP2Shell, l’équipe de sécurité de PHP a publié des correctifs source minimaux pour les branches 7.4 à 8.1 — mais aucune version officielle : quelqu’un doit les compiler et les installer, et ce quelqu’un n’est pas vous. C’est un geste exceptionnel, pas une garantie : la prochaine faille, ces branches ne la verront pas corrigée. Rester sur PHP 7.4 en 2026, c’est accepter d’être vulnérable par défaut.

Et migrer n’est pas une case à cocher : changer de branche PHP casse régulièrement des thèmes anciens, des extensions abandonnées et du code sur mesure écrit il y a dix ans. Ça se prépare, ça se teste, et ça se fait avec une sauvegarde complète avant.

Ce qui ne règle PAS le problème

• Mettre à jour WordPress. La faille est dans le moteur PHP, en dessous. Aucune version de WordPress ne la corrige.
• Mettre à jour vos extensions. Même raison.
• Installer une extension de sécurité. Utile par ailleurs, mais une extension s’exécute dans PHP : elle ne peut pas corriger PHP lui-même. Sur Apache/mod_php, l’exploitation survient même avant le chargement de WordPress.
• Avoir un site « tout petit » ou « pas intéressant ». Ces attaques sont automatisées et balayent des plages d’adresses entières. Personne n’a choisi votre site.

Questions fréquentes

Mon site affiche PHP 8.2.34 et le correctif est 8.2.35. Suis-je vulnérable ?

Impossible à dire depuis l’extérieur. Beaucoup d’hébergeurs rétroportent les correctifs de sécurité sans changer le numéro de version. Votre numéro est inférieur au correctif officiel, ce qui veut dire qu’il faut poser la question à votre hébergeur — pas que vous êtes forcément exposé.

Mon hébergeur dit qu’il a corrigé. Je dois faire autre chose ?

Deux choses. D’abord, demandez la date d’application : l’exploitation a commencé le 17 octobre, avant la sortie du correctif, donc une correction tardive laisse une fenêtre. Ensuite, si votre site tourne sur une branche en fin de vie (8.1 ou moins), planifiez la migration : pour ces branches, il n’existe aucune version officielle corrigée — seulement un correctif source que votre hébergeur doit compiler lui-même, et rien ne garantit qu’il le refera la prochaine fois.

Est-ce que WordPress est en cause ?

Non. La faille est dans PHP, le langage dans lequel WordPress est écrit et qui s’exécute sur le serveur. Tout site en PHP est concerné : WordPress, WooCommerce, Joomla, Drupal, Magento ou du code sur mesure.

Comment savoir si mon site a déjà été piraté ?

Cherchez des comptes administrateurs inconnus, des fichiers PHP apparus dans wp-content/uploads/, des tâches planifiées que vous n’avez pas créées et des redirections qui ne se déclenchent que depuis les résultats de recherche. En cas de doute sérieux, faites analyser le site : un webshell bien posé reste invisible depuis le tableau de bord.

Quelle version de PHP devrais-je viser ?

PHP 8.3 au minimum, idéalement 8.4. PHP 8.2 est corrigée mais arrive en fin de vie le 31 décembre 2026 — y migrer aujourd’hui, c’est refaire le travail dans 10 semaines.

On vérifie votre site gratuitement

Si vous n’avez pas envie de courir après votre hébergeur, on le fait pour vous. La vérification PHP2Shell est gratuite et comprend : la version réelle de votre moteur PHP, la confirmation écrite obtenue auprès de votre hébergeur, une recherche de signes de compromission, et un rapport d’une page en français clair. Si votre site tourne sur une branche en fin de vie, on vous dit ce que coûterait la migration — sans obligation.

Demander la vérification gratuite

Pour aller plus loin

• Pourquoi choisir un site WordPress professionnel pour votre PME
• Les 10 meilleurs hébergeurs web du Canada — la qualité de votre hébergeur détermine la vitesse à laquelle ce genre de correctif vous parvient
• Combien coûte l’hébergement d’un site web au Québec
• Développeur WordPress : quand faire appel à un spécialiste

Sources

• PHP Foundation — Today’s PHP Security Release
• Tenable — PHP2Shell : foire aux questions
• BleepingComputer — PHP warns admins of two critical flaws
• The Hacker News — PHP2Shell

Article publié le 22 octobre 2026. Les versions corrigées et les dates d’exploitation reflètent l’information disponible à cette date.