Faille PHP : que faire pour protéger votre site internet

Faille PHP corrigée le 21 octobre 2026 : vérifier si votre site est protégé, quoi demander à votre hébergeur et comment repérer un piratage.

La « faille PHP » corrigée le 21 octobre 2026 regroupe deux failles critiques, surnommées « PHP2Shell » par les chercheurs en sécurité. Elles peuvent permettre à un pirate, sans identifiant ni mot de passe, de lancer ses propres commandes sur le serveur de votre site, avec les droits du site. Selon PHP, toute installation qui fait fonctionner un site ou une application web est concernée.

Votre site ou votre application repose sur WordPress, PrestaShop ou un autre outil écrit en PHP ? Il reste exposé tant que PHP n’a pas été mis à jour sur le serveur, même s’il est bien conçu.

Ce qu’il faut savoir sur cette faille PHP

Annoncés par PHP la veille pour 16 h (heure de Paris), les correctifs sont sortis le 21 octobre. Selon l’avis de sécurité de PHP, une simple requête anonyme a suffi, dans certaines configurations, à démontrer une attaque, avant même que le site n’entre en jeu. Selon plusieurs sociétés de sécurité, des détails circulaient en ligne avant leur sortie.

Le CERT-FR, service d’alerte de l’ANSSI (l’agence nationale de cybersécurité), a publié une alerte. Il juge touchées toutes les versions de PHP 5 à 8.1, et les versions 8.2 à 8.5 antérieures aux correctifs. Depuis le 21 octobre, des sociétés de sécurité signalent des tentatives d’attaque, avec des constats encore divergents sur leur ampleur. Pour PHP, aucune parade n’est complète : seule la mise à jour protège.

Pourquoi mettre à jour WordPress ne suffit pas

Les failles sont dans PHP lui-même, le moteur qui fait tourner votre site, pas dans WordPress, PrestaShop ou les outils de développement. Mettre à jour extensions ou thème ne corrige donc rien : PHP doit être remplacé sur le serveur, puis redémarré. Méfiez-vous des extensions présentées comme des « correctifs PHP2Shell » : fonctionnant grâce à PHP, elles ne peuvent pas le réparer.

Pour l’une des failles, l’avis de PHP signale aussi une fuite d’informations de la mémoire du serveur. Selon des chercheurs, le pirate peut y récupérer mots de passe, données qui gardent un utilisateur connecté ou clés d’accès. Un site sans dégât visible a donc pu laisser fuir des informations sensibles.

Qui doit intervenir dépend de votre hébergement :

hébergement mutualisé (serveur partagé) ou plateforme gérée : l’hébergeur, pas vous ;
serveur dédié ou virtuel : vous ou votre prestataire d’infogérance ;
application en « conteneurs » (Docker par exemple) : celui qui la maintient, en la reconstruisant avec un PHP corrigé.

Vérifier si votre site est protégé

Relevez la version de PHP utilisée par votre site :

WordPress : Outils, puis Santé du site, onglet Infos, rubrique Serveur ;
PrestaShop : Paramètres avancés, puis Informations ;
Laravel, Symfony ou sur mesure : demandez à votre développeur la version utilisée par le serveur web, parfois différente de celle de la ligne de commande.

Une version 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou plus récente dans la même série, signifie que le correctif est actif. Une version plus ancienne n’est pas forcément vulnérable : PHP précise que les fournisseurs de systèmes Linux et de support prolongé ont reçu les correctifs à l’avance. Or ils peuvent intégrer un correctif sans changer le numéro de version affiché.

Dans le doute, demandez à votre hébergeur une confirmation écrite : correctifs des deux failles appliqués, PHP redémarré ensuite (sinon l’ancienne version continue de tourner), et date de l’intervention.

Si votre site tourne encore en PHP 8.1 ou 7.x

PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour officielles. PHP a tout de même publié des correctifs minimaux pour 7.4, 8.0 et 8.1, pour ceux qui fabriquent eux-mêmes leur PHP à partir du code source. Trois actions s’imposent :

chercher une version corrigée chez le fournisseur du système Linux ou une société de support prolongé, ou faire appliquer le correctif publié par PHP ;
appliquer dès aujourd’hui les deux mesures provisoires citées par le CERT-FR : désactiver le suivi de progression des envois de fichiers, et filtrer ces envois avec un pare-feu applicatif (un filtre placé devant le site) ;
planifier sans attendre le passage à une version maintenue.

Ces mesures réduisent le risque sans le supprimer : le CERT-FR ne les a pas validées, et la première ne couvre qu’une des deux failles. Ce filtrage bloque aussi les envois de fichiers légitimes et peut perturber certains formulaires, à tester. Pour les versions sans suivi, le CERT-FR recommande d’isoler les équipements concernés, puis de migrer. Visez PHP 8.3 au minimum, idéalement 8.4 ou 8.5 : selon le calendrier officiel de PHP, la 8.2 ne recevra plus de correctifs de sécurité après le 31 décembre 2026. Passer de PHP 7 à PHP 8 impose souvent d’adapter le code, à valider sur une copie de test.

Comment savoir si votre site a été piraté

Corriger PHP ne dit pas ce qui a pu se passer avant. Faites contrôler par votre hébergeur ou votre prestataire, au minimum :

les fichiers PHP récemment ajoutés ou modifiés sur le site : un pirate a pu y cacher une porte d’entrée ;
les nouveaux comptes administrateurs, sur le site comme sur le serveur ;
les tâches programmées inconnues et les programmes lancés par PHP ;
dans les journaux, des envois de fichiers inhabituels suivis d’erreurs de mémoire ou d’erreurs serveur répétées, et des redémarrages inexpliqués de PHP.

Aucun de ces signes n’est une preuve à lui seul, et leur absence ne garantit rien. En cas de doute, changez les codes d’accès stockés sur le serveur : base de données, liaisons avec d’autres logiciels, paiement, envoi d’e-mails. Conservez les journaux avant toute remise en état, pour l’analyse et une éventuelle plainte. Si des données personnelles ont pu être consultées, le RGPD impose de notifier la CNIL au plus tard 72 heures après en avoir pris connaissance, si la violation présente un risque pour les personnes.

À transmettre à votre hébergeur ou à votre prestataire

CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 (CVSS 4.0) ; alerte CERTFR-2026-ALE-014 ;
versions corrigées : 8.5.12, 8.4.27, 8.3.36, 8.2.35, puis redémarrage des processus PHP ;
risque maximal avec Apache et mod_php ; attaque validée aussi sur PHP-FPM pour l’une des failles ;
8.1 et antérieures : contournements non qualifiés par le CERT-FR, session.upload_progress.enabled à Off (php.ini ou pool PHP-FPM) puis redémarrage, et blocage au WAF, ou à défaut surveillance, des requêtes multipart.

Un exemple concret

Prenons, à titre d’illustration, une PME de 20 personnes : un site vitrine WordPress chez un hébergeur mutualisé, un espace client Laravel sur un serveur dédié en PHP 8.1. Le site vitrine affiche 8.3.36 dans Santé du site : le correctif est actif. L’espace client est plus délicat, faute de version officielle corrigée en 8.1. Le jour même, le prestataire désactive le suivi de progression des envois, filtre les envois de fichiers là où ils sont inutiles et cherche une version corrigée chez le fournisseur Linux. Il contrôle ensuite journaux et fichiers et fait renouveler les clés d’accès. Le passage à PHP 8.4, avec la mise à jour de Laravel qu’il implique, se prépare sur une copie de test.

Questions fréquentes

Mon site est chez un hébergeur mutualisé : que dois-je faire ?

Vous ne pouvez pas mettre PHP à jour vous-même. Vous pouvez en revanche vérifier la version affichée, demander une confirmation écrite à l’hébergeur et quitter une ancienne version (7.4 ou 8.1) si votre offre le permet.

Un pare-feu suffit-il à protéger mon site ?

Non. Un pare-feu applicatif peut bloquer des attaques connues et faire gagner du temps, mais ne filtre que le trafic qui passe par lui et ne corrige pas PHP.

Faut-il fermer mon site en attendant ?

Si la mise à jour tarde et que le site traite des paiements ou des données sensibles, couper l’accès est raisonnable, dans l’esprit de l’isolement recommandé par le CERT-FR. Le « mode maintenance » de WordPress ou d’une boutique ne protège pas : l’attaque a lieu avant que le site n’entre en jeu. La coupure doit donc se faire sur le serveur ou chez l’hébergeur.

Le 21 octobre, dès la publication des correctifs, 411bit a mis à jour PHP sur les serveurs des clients dont il assure l’infogérance. Pour faire le point, 411bit propose de vérifier la version de PHP de vos sites et applications, d’appliquer la mise à jour ou de vous accompagner auprès de votre hébergeur, de faire passer en version maintenue une application restée en PHP 8.1 ou 7.x et de rechercher d’éventuels signes de piratage, avec une réponse sous 24 heures ouvrées : décrivez-nous votre situation. Si votre application a été développée par un autre prestataire, la reprise d’une plateforme B2B industrielle illustre la démarche : un audit de sécurité d’abord, la reprise en main ensuite.