Un client vous a transféré un article sur une « faille critique dans PHP ». Votre site tourne sous WordPress, il marche très bien, et vous ne savez ni ce qu'est PHP ni qui doit s'en occuper.
La réponse courte : la faille PHP d'octobre 2026 concerne votre site WordPress, comme presque tous les sites écrits dans ce langage. Elle se corrige sur le serveur, avec une nouvelle version de PHP. Aucune extension ni mise à jour de WordPress n'y change rien.
Voyons donc ce qui s'est passé, comment savoir si votre site est exposé, qui doit installer le correctif et quoi faire si votre version de PHP est trop vieille. Pas besoin d'être développeur pour suivre.
Que s'est-il passé avec PHP en octobre 2026 ?
Le 20 octobre 2026, un message publié sur Hacker News a révélé l'existence de deux failles dans PHP, avant que leurs correctifs soient prêts. Le message a été retiré, mais les captures d'écran circulaient déjà.
Quelques heures plus tard, l'équipe de sécurité de PHP a confirmé deux vulnérabilités critiques. Elle a fixé la sortie des correctifs au 21 octobre 2026 à 16 h, heure de Paris.
Chacune des deux failles est notée 9,2 sur 10. Sansec, une société qui surveille la sécurité des boutiques en ligne, les classe parmi les failles d'exécution de code à distance. Une personne sans aucun accès à votre site peut alors faire exécuter ses propres commandes à votre serveur.
La note vient du barème CVSS, dans sa version 4.0, qui va de 0 à 10. À partir de 9, une faille entre dans la catégorie « critique », la plus haute du barème.
Les attaques n'ont pas attendu le correctif. D'après l'analyse de Sansec, Cloudflare a signalé les premières tentatives contre des sites en PHP le 21 octobre à 9 h 43, heure de Paris.
Sansec s'attend aussi à des attaques en masse dans le quart d'heure qui suit la sortie du correctif. Un correctif publié montre en effet, à qui sait le lire, l'endroit exact de la faille.
PHP a publié ses correctifs le 21 octobre 2026, un peu avant l'heure annoncée. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. D'après l'avis de sécurité de PHP, la première faille se déclenche quand PHP manque de mémoire en pleine requête. La seconde laisse traîner les données d'une requête, qu'une requête suivante peut réutiliser.
Pourquoi votre site WordPress est-il concerné ?
WordPress est écrit en PHP, un langage de programmation qui tourne sur le serveur. À chaque visite, votre serveur lance PHP, qui lit le code de WordPress, de votre thème et de vos extensions. Il fabrique ensuite la page envoyée au visiteur.
La faille ne se trouve pas dans WordPress, mais dans PHP lui-même. Imaginez une galerie marchande. Votre site est une boutique, PHP est le bâtiment.
Elle est dans la porte d'entrée de la galerie. Changer la serrure de votre boutique n'empêche personne d'entrer dans le hall.
C'est pour ça qu'aucune extension de sécurité ne protège votre site contre ces deux failles. Pour Sansec, la correction se fait sur le serveur, pas dans le code du site.
Sont concernés, d'après les sociétés de sécurité qui ont étudié la fuite :
- les sites WordPress, boutiques WooCommerce comprises ;
- les sites faits avec un autre outil écrit en PHP, comme Drupal, Joomla, PrestaShop ou Magento ;
- les applications maison en PHP, par exemple un site construit avec Symfony ou Laravel.
Votre site est fait avec Wix, Shopify ou Webflow ? Vous n'avez aucun serveur à gérer. C'est à la plateforme de se protéger, et vous n'avez rien à faire.
Le mode maintenance de WordPress ne vous met pas à l'abri. D'après Sansec, PHP lit chaque requête avant même que WordPress vérifie si le site est en maintenance. Pour mettre un site hors d'atteinte, il faut le couper au niveau du serveur.
Comment savoir quelle version de PHP utilise votre site ?
La version compte, parce qu'elle décide si votre site recevra un correctif. Seules les versions 8.2 à 8.5 de PHP sont encore maintenues par l'équipe de PHP, et les correctifs de sécurité ne vont normalement qu'à elles.
Dans WordPress, vous trouvez la version en quelques clics :
- ouvrez votre tableau de bord WordPress ;
- allez dans Outils, puis dans Santé du site ;
- cliquez sur l'onglet Infos ;
- dépliez la rubrique Serveur et lisez la ligne qui donne la version de PHP.
Pas d'accès au tableau de bord ? L'espace client de votre hébergeur donne aussi la version de PHP, en général dans une rubrique qui lui est consacrée.
Qui doit installer le correctif, vous ou votre hébergeur ?
Tout dépend de qui gère le serveur sur lequel tourne votre site :
- sur un hébergement mutualisé, où vous partagez un serveur avec d'autres clients (chez o2switch, OVHcloud, Hostinger ou IONOS par exemple), votre hébergeur installe les nouvelles versions de PHP sur ses machines ;
- sur un hébergement WordPress géré, où l'hébergeur s'occupe de tout, c'est aussi à lui d'agir ;
- sur un serveur à vous, un VPS loué au mois et que vous administrez vous-même, c'est à vous de mettre PHP à jour.
Sur un mutualisé, vous n'avez donc aucune commande à taper. Votre travail consiste à vérifier que votre hébergeur a bien appliqué le correctif, et à lui demander quand s'il ne dit rien.
Deux lignes suffisent : « Bonjour, mon site [adresse] tourne en PHP [version]. Pouvez-vous me confirmer que le correctif de sécurité PHP du 21 octobre 2026 (CVE-2026-109618 et CVE-2026-109619) est appliqué sur mon serveur ? » Les deux références disent tout de suite au support de quoi vous parlez.
Chez Believemy, nous avions encore un vieux serveur en PHP 7.4 sur nos tests en interne, une version que plus personne ne corrige depuis 2022. Le 21 octobre, plutôt que de chercher à le sauver, nous l'avons tout simplement arrêté.
Que faire si votre site tourne encore en PHP 7.4, 8.0 ou 8.1 ?
Ces trois versions ne reçoivent plus de nouvelle version de l'équipe de PHP. Elle a seulement fourni des correctifs minimaux à compiler soi-même, pour ceux qui gèrent leur propre serveur. Sur un hébergement mutualisé, demandez à votre hébergeur s'il les a appliqués. Mieux encore, passez à une version maintenue.
Le CERT-FR, le centre gouvernemental qui alerte sur les attaques informatiques en France, recommande d'isoler les serveurs concernés, puis de passer à une version maintenue.
Voici jusqu'à quand chaque version reçoit des correctifs de sécurité, d'après la page des versions maintenues de PHP.
| Version de PHP | Correctifs de sécurité jusqu'au |
|---|---|
| 8.5 | 31 décembre 2029 |
| 8.4 | 31 décembre 2028 |
| 8.3 | 31 décembre 2027 |
| 8.2 | 31 décembre 2026 |
| 8.1 | terminé le 31 décembre 2025 |
| 8.0 | terminé le 26 novembre 2023 |
| 7.4 | terminé le 28 novembre 2022 |
Visez PHP 8.3 ou plus récent. La 8.2 cesse d'être corrigée le 31 décembre 2026. Y passer en octobre vous obligerait à recommencer en janvier.
Pour changer de version sans casser votre site, procédez dans cet ordre :
- faites une sauvegarde complète, fichiers et base de données ;
- mettez à jour WordPress, votre thème et vos extensions, car une extension abandonnée peut refuser de fonctionner sur une version récente ;
- changez la version de PHP dans l'espace client de votre hébergeur ;
- parcourez votre site, de l'accueil au formulaire de contact, avec une commande test si vous vendez.
Une page tombe en erreur ? Revenez à l'ancienne version le temps de remplacer l'extension fautive, puis réessayez. Ne restez pas des semaines sur une version que plus personne ne corrige.
Comment protéger votre site en attendant le correctif ?
Votre hébergeur peut mettre plusieurs heures à installer la nouvelle version. Et un site sur une version qui n'est plus maintenue n'en recevra peut-être jamais. Deux protections provisoires existent.
Passer votre site derrière Cloudflare, même avec l'offre gratuite. D'après son directeur technique, cité par Sansec, Cloudflare a déployé des règles contre les attaques connues pour tous ses clients.
Sansec précise que ces règles servent à tenir en attendant la mise à jour, sans la remplacer. Et le changement de DNS (le carnet d'adresses qui relie votre nom de domaine à votre serveur) peut prendre quelques heures.
Couper le site, si vous pouvez vous en passer une journée : demandez à votre hébergeur de le suspendre. Plusieurs sites néerlandais l'ont fait le 21 octobre par précaution, dont celui du centre national de cybersécurité des Pays-Bas, d'après Sansec.
Les contournements du CERT-FR, pour les développeurs
Si quelqu'un d'autre gère votre serveur, vous pouvez sauter cette partie. Elle sert à ceux qui administrent eux-mêmes leur machine, le temps d'installer la nouvelle version.
Le CERT-FR propose deux mesures, qu'il dit ne pas avoir validées lui-même. La première consiste à couper une option dans le fichier php.ini.
session.upload_progress.enabled = OffCette ligne désactive le suivi de progression des envois de fichiers. D'après le CERT-FR, elle ne protège que contre l'une des deux failles.
La seconde bloque toutes les requêtes au format multipart/form-data, celui qu'un navigateur utilise pour envoyer un fichier. Avec nginx, Sansec propose cette règle :
if ($http_content_type ~* "multipart/form-data") {
return 403;
}Toute requête qui envoie un fichier reçoit alors un refus. En contrepartie, plus aucun envoi de fichier ne fonctionne, médiathèque WordPress comprise, et parfois le panier d'une boutique. Retirez la règle dès que PHP est à jour.
Retenez surtout le premier geste. Lisez votre version de PHP dans WordPress, puis écrivez deux lignes à votre hébergeur. Le reste, c'est son travail.
Questions fréquentes sur la faille PHP d'octobre 2026
Une extension de sécurité WordPress protège-t-elle contre la faille PHP d'octobre 2026 ?
Non. Les deux failles se trouvent dans PHP, le langage qui fait tourner WordPress, et non dans WordPress. Seule une nouvelle version de PHP, installée sur le serveur, les corrige.
Les règles de Cloudflare ou le blocage des envois de fichiers limitent les attaques en attendant, sans remplacer cette mise à jour.
Comment savoir si mon site WordPress utilise une version de PHP à risque ?
Dans WordPress, ouvrez Outils, puis Santé du site, onglet Infos, rubrique Serveur. Les versions 8.2 à 8.5 sont maintenues par l'équipe de PHP.
Les versions 7.4, 8.0 et 8.1 ne reçoivent plus de correctifs : passez à PHP 8.3 ou plus récent.
Est-ce à moi ou à mon hébergeur d'installer le correctif PHP ?
Sur un hébergement mutualisé ou un hébergement WordPress géré, c'est l'hébergeur qui met PHP à jour. Demandez à son support si le correctif du 21 octobre 2026 est appliqué.
Sur un serveur que vous administrez vous-même, comme un VPS, c'est à vous de l'installer.
Quelle est la gravité de la faille PHP d'octobre 2026 ?
Chacune des deux failles est notée 9,2 sur 10 sur le barème CVSS, ce qui les classe parmi les failles critiques. D'après Sansec, elles permettent de faire exécuter des commandes à un serveur sans y avoir accès.
Des tentatives d'attaque ont été signalées le 21 octobre 2026, avant même la sortie du correctif.
