Le 21 octobre 2026, les développeurs de PHP ont corrigé deux failles critiques qui permettent de prendre le contrôle d’un site à distance, sans mot de passe. WordPress, PrestaShop et la plupart des sites d’entreprise tournent sur PHP. La parade est simple : passer à une version corrigée, ou quitter une version qui n’est plus suivie.
Ce qui se passe
PHP est le langage qui fait fonctionner votre site sur le serveur : c’est lui qui fabrique les pages, enregistre les commandes et envoie les formulaires. Deux failles y ont été découvertes (références CVE-2026-109618 et CVE-2026-109619), notées 9,2 sur 10 en gravité. Une simple requête envoyée au site peut suffire à y exécuter le code d’un pirate, avant même que WordPress ou PrestaShop n’aient démarré.
L’ANSSI (via le CERT-FR) et Cybermalveillance.gouv.fr ont publié une alerte le 22 octobre. Le CERT-FR indique avoir connaissance de programmes de démonstration de l’attaque : les pirates n’auront pas à tout inventer, et des attaques massives sont à craindre dans les jours qui viennent.
Ce que permet la faille : voler ou effacer vos données (clients, commandes, comptes), rendre le site inaccessible, y glisser des pages de pub ou d’arnaque, ou s’en servir comme porte d’entrée vers le reste de votre informatique.
Les boutiques en ligne et les sites reliés à un logiciel interne (gestion, facturation, intranet) sont les plus exposés.
Mon site est-il concerné ?
Oui, s’il utilise PHP et que sa version fait partie de la liste ci-dessous. C’est le cas de tous les sites WordPress, WooCommerce, PrestaShop, Joomla ou Drupal, et de beaucoup de sites faits sur mesure. Peu importe le thème ou les extensions : c’est le moteur lui-même qui est touché.
| Version de PHP | Situation au 23 octobre 2026 | Ce qu’il faut faire |
|---|---|---|
| 8.5 | Corrigée à partir de 8.5.12 | Mettre à jour en 8.5.12 ou plus |
| 8.4 | Corrigée à partir de 8.4.27 | Mettre à jour en 8.4.27 ou plus |
| 8.3 | Corrigée à partir de 8.3.36 | Mettre à jour en 8.3.36 ou plus |
| 8.2 | Corrigée à partir de 8.2.35, plus suivie après le 31 décembre 2026 | Mettre à jour, puis prévoir le passage en 8.3 ou plus |
| 8.1, 8.0, 7.x, 5.x | Plus suivies par PHP : la faille reste ouverte | Passer à une version suivie, au plus vite |
Le dernier cas est le plus fréquent sur les sites qui n’ont pas été touchés depuis plusieurs années : le site marche, personne n’y pense, et il tourne encore en PHP 7.4 ou 8.0. C’est justement celui-là qu’il faut regarder en premier.
Vérifier sa version en deux minutes
- Sur WordPress : dans l’administration, menu Outils › Santé du site, onglet Informations, rubrique Serveur. La ligne « Version de PHP » affiche le numéro exact.
- Sur PrestaShop : menu Paramètres avancés › Informations, partie « Informations sur le serveur ».
- Dans l’espace de votre hébergeur (Plesk, cPanel, OVHcloud…) : la version de PHP est indiquée dans les réglages du site ou de l’hébergement.
- Comparez le numéro avec le tableau ci-dessus. Le chiffre après le deuxième point compte : 8.3.30 n’est pas corrigé, 8.3.36 l’est.
Si vous n’avez accès à rien de tout cela, demandez simplement à la personne ou à l’agence qui s’occupe de votre site : « Quelle version de PHP fait tourner mon site, et a-t-elle reçu le correctif du 21 octobre ? » La réponse doit être claire et rapide.
Que faire selon votre cas
Version récente, pas encore corrigée
La mise à jour se fait chez l’hébergeur, sans toucher au site. Sur un hébergement mutualisé, elle est en général appliquée par l’hébergeur lui-même : vérifiez quand même le numéro. Sur un serveur dédié ou un VPS, c’est à vous (ou à votre prestataire) de l’installer.
PHP 8.1 ou plus ancien
Il faut changer de version, et c’est là qu’il faut être prudent : un thème ou une extension trop vieux peut casser le site en PHP 8.3 ou 8.4. On fait une sauvegarde, on teste sur une copie, on corrige ce qui bloque, puis on bascule.
Sauvegarde d’abord, et un œil sur le site
Avant toute bascule, une sauvegarde complète (fichiers et base de données) que l’on sait restaurer. Ensuite, surveillez les signes d’une intrusion : comptes administrateurs inconnus, pages ou redirections bizarres, alerte de Google ou de votre hébergeur.
Si la mise à jour est impossible tout de suite, l’éditeur de PHP et le CERT-FR décrivent des réglages d’attente (par exemple désactiver la fonction de suivi des envois de fichiers dans la configuration de PHP). Ils réduisent le risque mais ne rendent pas le site sûr : ils ne remplacent pas la mise à jour. Pour la règle de sauvegarde à suivre, voyez notre article sur la règle 3-2-1.
Un site qui marche n’est pas un site à jour : la faille ne se voit pas avant le jour où elle sert.
Cette alerte est aussi le bon moment pour faire le tour du reste : version de WordPress ou de PrestaShop, extensions abandonnées, comptes d’anciens prestataires. C’est le travail d’une maintenance régulière, qui évite de courir après chaque alerte.
$ qweb audit --phpUn doute sur votre site ? On le vérifie
QWEB contrôle la version de PHP de votre site, sa compatibilité avec une version suivie, vos extensions et vos sauvegardes, puis fait la mise à jour sans casser le site si besoin.
