Failles de sécurité PHP en octobre 2026 : votre site WordPress est-il vraiment protégé ?

Si votre site WordPress tourne sur PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 ou sur une version corrigée par votre hébergeur, il est protégé contre PHP2Shell, les deux failles critiques (9,2/10) corrigées le 21 octobre 2026.

Sauf que ces versions ne bloquent pas la troisième faille signalée le 23 octobre. Et sur un hébergement mutualisé, le numéro affiché dans cPanel, dans WordPress ou dans le terminal ne correspond pas toujours au PHP qui exécute réellement votre site. Certains hébergeurs ont même corrigé leurs serveurs avant de mettre à jour le numéro de version.

Je vous explique ce que permettent ces failles, ce qu’ont fait o2switch, OVHcloud et Infomaniak, et surtout comment vérifier vous-même que votre site est couvert.

Avant d’entrer dans le détail, voici le minimum à faire :

1. Dans WordPress, allez dans Outils → Santé du site → Informations → Serveur et notez la version PHP.
2. Comparez-la avec le tableau des versions corrigées plus bas.
3. Si votre numéro est plus ancien, consultez l’annonce de votre hébergeur : il a peut-être appliqué le correctif sans changer le numéro.
4. Pas d’annonce claire ? Envoyez au support les questions listées dans la partie « Que demander à son hébergeur ? ».

Le reste de l’article explique pourquoi chaque étape compte.

Le 20 octobre 2026, l’équipe PHP a annoncé des correctifs de sécurité exceptionnels. Ils ont été publiés le 21 octobre pour corriger deux vulnérabilités, regroupées sous le nom de PHP2Shell :

Un score de 9,2 correspond à une gravité critique. Les deux failles peuvent permettre à un attaquant d’exécuter du code malveillant à distance, sans compte administrateur.

Quand une requête provoque certaines erreurs d’allocation mémoire, PHP peut manipuler des données internes mal initialisées. Un attaquant peut exploiter ce comportement avec des requêtes HTTP construites pour l’occasion, provoquer une corruption mémoire et potentiellement exécuter du code.

Ici, certaines informations internes subsistent après la libération de leur mémoire. Quand un même processus PHP traite plusieurs requêtes à la suite, des références devenues invalides peuvent être réutilisées, ce qui ouvre la porte à une corruption de mémoire exploitable.

La plupart des failles de sécurité WordPress concernent une extension ou un thème mal codé. Là, la faille se trouve directement dans PHP. Un site WordPress parfaitement à jour pouvait donc être exposé si son serveur utilisait une version vulnérable.

Plusieurs modes d’exécution sont concernés :

• PHP-FPM
• PHP-CGI
• Apache mod_php (risque jugé particulièrement élevé par le projet PHP)
• LiteSpeed

Le niveau de risque réel dépend de la configuration du serveur.

Tous mes clients sont sur des hébergements mutualisés. Je n’avais donc rien à installer moi-même : les correctifs, c’est l’hébergeur qui les déploie. Mon travail a consisté à vérifier, site par site, que la bascule s’était bien passée et que chaque site tournait réellement sur une version corrigée.

Ces failles ne sont pas restées théoriques. D’après Cloudflare, les tentatives d’exploitation ont explosé juste après la divulgation :

Une tentative n’est pas un piratage réussi : ces chiffres ne veulent pas dire que des millions de sites ont été compromis. Ils montrent par contre à quelle vitesse une faille critique est exploitée à grande échelle. Quelques heures, c’est souvent moins que le temps qu’il faut à un propriétaire de site pour voir passer l’alerte.

Source : Cloudflare : protections contre PHP2Shell

Une exécution de code à distance (RCE, pour Remote Code Execution) peut faire beaucoup de dégâts. Selon les permissions du processus PHP et les protections de votre hébergement, un attaquant pourrait :

• modifier des fichiers du site ou y injecter du code malveillant ;
• accéder à des données sensibles ou à des fichiers de configuration comme le wp-config.php ;
• installer une porte dérobée pour garder un accès ;
• rendre le site indisponible ;
• utiliser votre hébergement pour d’autres activités malveillantes.

Tunnel de commande en panne, modifications frauduleuses, données clients exposées : les conséquences sont à la fois financières, techniques et juridiques. Si des données personnelles sont réellement compromises, vous devez aussi évaluer vos obligations au regard du RGPD.

Gardez quand même la tête froide : avoir tourné sur une version vulnérable ne veut pas dire que votre site a été piraté. Le risque d’exploitation et une compromission constatée sont deux choses différentes.

Il n’existe pas de signe propre à PHP2Shell. Une attaque réussie laisse en revanche les mêmes traces qu’un piratage classique, et les symptômes d’un site WordPress piraté restent les mêmes :

• des fichiers PHP inconnus ou modifiés récemment, notamment dans le dossier wp-content/uploads ;
• un compte administrateur que vous n’avez pas créé ;
• des redirections vers des sites douteux ou du contenu ajouté à votre insu ;
• un avertissement de Google ou de votre hébergeur ;
• une activité inhabituelle dans les journaux du serveur.

Pour vérifier, lancez un scan avec l’une des meilleures extensions de scan antivirus WordPress et consultez les logs de votre site WordPress. Si vous trouvez quelque chose d’anormal, voici comment récupérer et sécuriser un site WordPress piraté.

PHP 8.1 et les versions plus anciennes ne bénéficient plus du support officiel. Certains fournisseurs de support étendu proposent quand même des correctifs, sans forcément changer le numéro principal de version.

Conséquence directe : une version antérieure au correctif officiel n’est pas forcément vulnérable si elle a reçu un correctif adapté. On y revient plus bas avec les backports.

Source : communiqué officiel PHP du 21 octobre 2026

Pendant que les hébergeurs terminaient le déploiement des correctifs PHP2Shell, une nouvelle alerte est tombée le 23 octobre : CVE-2026-115560.

Bonne nouvelle, celle-ci demande une configuration très particulière pour être exploitable.

Elle touche le suivi de progression des fichiers envoyés au serveur, session.upload_progress. Pour qu’un site soit exposé, toutes ces conditions doivent être réunies :

• PHP utilise au départ php_binary ou php_serialize comme gestionnaire de sérialisation des sessions ;
• l’application change ce paramètre en cours d’exécution pour passer à php ;
• ce changement a lieu avant l’appel à session_start() ;
• le suivi de progression des envois de fichiers est activé.

L’équipe PHP considère cette combinaison comme inhabituelle. Tous les sites WordPress ne sont donc pas concernés : une application qui ne modifie jamais le gestionnaire de sérialisation en cours d’exécution n’est pas exposée à ce scénario.

Cette faille est distincte de PHP2Shell. Elle n’est pas corrigée par PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12.

Au 23 octobre 2026, PHP prévoit un correctif dans son cycle normal de maintenance et n’a pas encore communiqué de score CVSS définitif.

Le projet PHP recommande temporairement :

session.upload_progress.enabled = 0

Ce réglage désactive le suivi natif de progression des envois de fichiers. Il était déjà conseillé pour limiter certains scénarios d’exploitation de CVE-2026-109619.

Pour qu’il protège vraiment, il doit être appliqué au bon niveau de configuration serveur, avant le traitement des requêtes, et les processus PHP doivent être redémarrés. Un snippet PHP ou une ligne ajoutée dans un fichier WordPress ne vous garantit rien.

Sur un mutualisé, je vous conseille de demander à votre hébergeur si c’est déjà en place plutôt que de modifier votre configuration à l’aveugle.

Source : Security Affairs : nouvelle vulnérabilité PHP du 23 octobre

Sur un mutualisé classique, vous ne gérez pas le moteur PHP installé sur le serveur. C’est l’hébergeur qui déploie les correctifs, maintient PHP et administre l’environnement.

Votre rôle à vous :

• utiliser une branche PHP encore maintenue ;
• vous assurer que votre hébergeur a bien appliqué les mises à jour de sécurité.

Le problème, c’est que chaque hébergeur communique à sa façon. Voici où en étaient les trois principaux.

Dans une communication du 23 octobre, o2switch confirme avoir déployé les correctifs PHP2Shell sur toutes les versions proposées dans cPanel, de PHP 5.2 à PHP 8.5. L’hébergeur a aussi désactivé par défaut le suivi de progression des envois de fichiers, ce qui répond à la troisième alerte.

Dans un premier temps, les versions corrigées conservaient leur ancien numéro. o2switch conseillait alors de vérifier une date de compilation au 21 octobre 2026 ou plus récente.

Environ 24 heures après le déploiement des correctifs, l’hébergeur a mis à jour sa nomenclature : les versions affichées dans cPanel portent désormais les bons numéros corrigés, comme 8.3.36 ou 8.4.27. Si vous êtes chez o2switch et que vous voyez encore un ancien numéro, c’est que votre site n’utilise pas la version que vous pensez.

Pour consulter votre version :

1. Connectez-vous à votre cPanel.
2. Ouvrez « Sélectionner une version de PHP ».
3. Notez la version choisie.
4. Comparez-la avec celle réellement utilisée par WordPress.

Source : o2switch : faille PHP2Shell

OVHcloud a déployé les correctifs sur PHP 7.4 à 8.5 dès le 21 octobre, puis confirmé le 23 octobre la fin du déploiement pour PHP 5.3 à 7.3.

Pour consulter votre configuration :

1. Connectez-vous à l’espace client OVHcloud.
2. Allez dans votre hébergement web.
3. Ouvrez les informations générales.
4. Regardez la version PHP globale.

Si votre installation est particulière, vérifiez aussi les fichiers .ovhconfig, qui peuvent définir la configuration PHP réellement appliquée.

Source : OVHcloud : suivi officiel des correctifs

Infomaniak confirme avoir appliqué les correctifs PHP2Shell sur PHP 7.4 à 8.5, sur ses hébergements mutualisés et ses Serveurs Cloud. L’hébergeur précise que les numéros affichés peuvent rester inchangés.

Pour vérifier votre version :

1. Connectez-vous au Manager Infomaniak.
2. Sélectionnez l’hébergement et le site concerné.
3. Allez dans les informations du produit.
4. Regardez la version PHP utilisée.

Source : Infomaniak : modifier la version PHP d’un site

Si vous êtes ailleurs, en particulier sur un mutualisé sous CloudLinux, cPanel ou Plesk, cherchez les annonces officielles de votre prestataire. Sans confirmation, contactez le support en citant précisément CVE-2026-109618, CVE-2026-109619 et CVE-2026-115560.

Un pare-feu applicatif (WAF) comme celui de Cloudflare ajoute une couche de protection, mais il ne remplace pas les correctifs PHP.

C’est le point que presque tout le monde néglige.

Vous sélectionnez PHP 8.3 dans cPanel, WordPress affiche PHP 8.1, et en SSH php -v vous répond PHP 8.4. Trois résultats pour un seul hébergement.

Je l’ai vécu cette semaine : chez l’un de mes clients, la version PHP corrigée n’était pas prise en compte à cause du cache. L’hébergeur avait fait son travail, mais le site ne tournait pas encore sur la bonne version. Sans vérification, personne ne s’en serait rendu compte.

Le cache n’est pas la seule explication possible. Voici les causes à passer en revue.

Sur certains hébergements CloudLinux + cPanel, deux outils coexistent :

• MultiPHP Manager sélectionne une version PHP pour un domaine ;
• PHP Selector (« Sélectionner une version de PHP ») choisit un environnement PHP et ses extensions pour tout le compte.

Ils ne fonctionnent pas de la même façon. Dans une configuration CloudLinux classique, si MultiPHP Manager impose une autre version que la version native, son réglage peut passer devant celui de PHP Selector. Vous croyez utiliser la version choisie dans PHP Selector, votre site tourne sur une autre.

Quand c’est PHP Selector qui doit piloter la version du compte, la documentation cPanel recommande généralement de laisser le domaine en mode « inherit » dans MultiPHP Manager. Ce réglage doit toutefois être compatible avec le gestionnaire PHP de votre hébergeur, donc ne le changez pas sans avoir vérifié votre configuration.

Chez o2switch, par exemple, l’onglet « Paramètres par domaine » de PHP Selector montre pour chaque domaine s’il suit la version du compte (« défaut du compte ») ou une version qui lui est propre. C’est le premier endroit à regarder quand un site ne tourne pas sur la version attendue.

Sur certaines infrastructures, le .htaccess contient des directives qui indiquent quel gestionnaire PHP doit exécuter le site. Une directive héritée d’un ancien environnement peut fausser la sélection.

Ça arrive surtout après une migration, une modification manuelle ou une restauration de sauvegarde. Vérifiez le .htaccess du domaine et, si besoin, ceux des dossiers parents. Si vous ne savez pas où il se trouve, j’explique comment trouver et modifier le fichier .htaccess de WordPress.

Par contre, ne supprimez pas les directives PHP au hasard : certaines sont indispensables au fonctionnement de votre hébergement.

La commande php -v interroge PHP en mode CLI, c’est-à-dire la version utilisée par la ligne de commande. Sur un mutualisé qui propose plusieurs environnements PHP, elle peut très bien différer de celle qui exécute votre site web.

Pour WordPress, ce qui compte, c’est la version utilisée lors d’une vraie requête web.

PHP-FPM et LiteSpeed LSAPI reposent sur des processus PHP qui restent actifs entre plusieurs requêtes. Après une mise à jour ou un changement de configuration, l’environnement réellement utilisé dépend de la façon dont ces processus ont été rechargés.

Des processus mal renouvelés peuvent donc faire tourner temporairement l’ancien environnement. Sur un mutualisé, c’est à l’hébergeur d’intervenir : si votre changement de version ne prend pas après vérification des réglages, demandez au support de contrôler les gestionnaires et processus PHP.

OPcache garde en mémoire le code PHP déjà compilé pour accélérer l’exécution des scripts. Il faut bien séparer trois choses :

OPcache ne transforme pas PHP 8.3 en PHP 8.4 et ne change pas la valeur de PHP_VERSION. Le vider ne réglera donc pas un écart de version entre cPanel et WordPress. Lors de certaines mises à jour, le redémarrage des processus et la remise à zéro des caches d’opcodes font en revanche partie des opérations techniques côté hébergeur.

Un cache de page peut, lui, renvoyer une vieille page de diagnostic avec des informations dépassées. Ça ne veut pas dire que le serveur exécute encore l’ancienne version.

Bref, le cache ne change pas le moteur PHP lui-même, mais il peut retarder la prise en compte d’une nouvelle version ou vous montrer une information dépassée. Chez mon client, c’est lui qui bloquait. C’est pour ça que je ne l’écarte jamais, et que je vous conseille de savoir vider le cache de votre site WordPress après un changement de version.

Ne vous fiez pas uniquement au panneau de votre hébergeur. Croisez plusieurs sources. Si vous voulez le pas à pas détaillé, j’ai écrit un guide complet pour vérifier la version PHP de votre site WordPress.

1. Allez dans Outils → Santé du site.
2. Cliquez sur Informations.
3. Ouvrez la rubrique Serveur.
4. Repérez la version de PHP.

C’est l’environnement qui a exécuté WordPress au moment de cette requête. Dans l’exemple ci-dessous, le site tourne bien sur PHP 8.3.36, la version corrigée de la branche 8.3.

Pour aller plus loin, créez temporairement un fichier PHP contenant :

<?php phpinfo(); ?>

Placez-le dans le dossier réellement utilisé par le domaine, par exemple en vous connectant au serveur de votre site en SFTP, puis ouvrez-le dans votre navigateur. Idéalement, protégez son accès, car phpinfo() expose beaucoup d’informations techniques.

Supprimez le fichier dès que vous avez fini. Un phpinfo() qui traîne en accès public, c’est une carte détaillée de votre serveur offerte à n’importe qui.

Notez la version configurée dans MultiPHP Manager et, si vous l’avez, dans PHP Selector. Comparez avec ce que vous ont donné WordPress et phpinfo(). En cas d’écart, vérifiez les réglages d’héritage et les directives PHP du .htaccess.

C’est le piège principal de cette affaire.

Un hébergeur peut intégrer un correctif de sécurité sans passer à la nouvelle version officielle de PHP. On appelle ça un backport.

CloudLinux a par exemple publié un paquet PHP en révision 8.3.35-6 qui intègre les corrections PHP2Shell. Le numéro principal reste 8.3.35, mais le correctif est bien là. Et phpinfo() peut afficher simplement « PHP 8.3.35 », sans la révision du paquet. C’est aussi ce qu’ont vécu les clients o2switch pendant les 24 heures qui ont précédé la mise à jour des numéros.

La date de compilation donne un indice, surtout quand l’hébergeur communique une date précise de déploiement. Mais une date récente ne prouve pas à elle seule que le correctif est présent. Pour confirmer un backport, il faut connaître le paquet réellement installé ou avoir une confirmation officielle du fournisseur.

Procédez dans cet ordre :

Ne changez pas de branche PHP juste parce que le terminal affiche un autre numéro. Commencez par identifier l’environnement qui exécute vraiment votre site.

Si vous n’arrivez pas à confirmer que votre environnement est corrigé, voici les questions à envoyer au support :

• Les correctifs CVE-2026-109618 et CVE-2026-109619 sont-ils appliqués à la version PHP qui exécute mon site ?
• Si le numéro n’a pas changé, quel est le numéro de révision du paquet corrigé ?
• La directive session.upload_progress.enabled est-elle désactivée au bon niveau en attendant le correctif de CVE-2026-115560 ?
• Quel gestionnaire PHP exécute réellement mon site : PHP-FPM, LSAPI ou un autre ?
• Comment expliquer l’écart entre la version choisie dans cPanel et celle affichée par WordPress ?

Avec des questions aussi précises, vous obtenez une vraie réponse technique au lieu d’un « nos serveurs sont à jour ».

Sur un mutualisé, les correctifs de sécurité du moteur PHP sont installés par l’hébergeur. Vous pouvez en revanche choisir une branche plus récente depuis votre panneau d’administration.

Ce n’est pas un clic anodin. Changer de version PHP peut faire apparaître des incompatibilités dans votre thème, vos extensions ou votre code personnalisé. Avant de toucher à quoi que ce soit :

• faites une sauvegarde complète et récente de votre site WordPress ;
• testez si possible sur une préproduction ;
• vérifiez ensuite les fonctions critiques : formulaires, connexion, panier, paiement, traitement des commandes.

Si votre site tourne encore sous PHP 8.1 ou plus ancien, prévoyez une migration. Je détaille la méthode dans mon article sur comment mettre à jour PHP sur WordPress. Et notez que PHP 8.2 arrive lui aussi en fin de support officiel le 31 décembre 2026.

Cette semaine d’octobre montre une réalité que beaucoup de propriétaires de sites sous-estiment.

Vous pouvez avoir WordPress, WooCommerce, votre thème et toutes vos extensions à jour sans être totalement protégé. Parce que votre site repose sur un environnement serveur : PHP, ses gestionnaires, ses correctifs et sa configuration font partie de votre sécurité, au même titre que le reste.

Et c’est là qu’un numéro de version devient trompeur. Voir PHP 8.3.35 ne suffit pas à dire que votre site est vulnérable. Voir une date de compilation récente ne suffit pas non plus à dire qu’il est protégé. Ce qui compte, c’est le correctif réellement installé sur le PHP qui exécute votre site.

Cette semaine, aucun de mes clients n’avait d’action à faire sur son serveur. Pourtant, sans vérification, l’un d’eux serait resté sur une version non corrigée à cause du cache. C’est exactement pour ça que la maintenance d’un site WordPress est essentielle : l’hébergeur déploie le correctif, mais quelqu’un doit vérifier qu’il s’applique vraiment à votre site.

En tant que développeuse WordPress spécialisée en cybersécurité, je surveille cette couche serveur même quand l’hébergement est mutualisé. La sécurité d’un site ne devrait pas dépendre d’une alerte croisée par hasard sur les réseaux sociaux.

Deux failles critiques corrigées en urgence, une troisième signalée deux jours plus tard, des hébergeurs qui corrigent avant de mettre à jour les numéros de version : un site à jour côté WordPress ne suffit plus pour être tranquille.

Pour savoir où vous en êtes, vérifiez le PHP qui exécute réellement votre site, lisez l’annonce de votre hébergeur et demandez confirmation dès que les informations se contredisent. Un site qui fonctionne n’est pas forcément un site sécurisé.

Vous préférez vous concentrer sur votre activité plutôt que sur les CVE et les réglages serveur ? Avec mon service de maintenance WordPress, je m’occupe du suivi technique, des mises à jour, de la veille sur les vulnérabilités et de la sécurité de votre site.

Votre site, ce n’est plus votre problème. C’est le mien.

• PHP : alertes officielles des 21 et 23 octobre 2026
• Security Affairs : nouvelle vulnérabilité PHP CVE-2026-115560
• Cloudflare : protections contre PHP2Shell
• o2switch : correctifs PHP2Shell
• OVHcloud : suivi des correctifs
• Infomaniak : versions et correctifs PHP
• cPanel : MultiPHP Manager et PHP Selector
• PHP : documentation officielle OPcache