Mon hébergeur dit avoir corrigé PHP. Que me reste-t-il à faire ?

WindowsMacMis à jour 2026-10-31

Le correctif de votre hébergeur met à jour PHP, le langage avec lequel ses serveurs font tourner votre site. Le projet PHP a publié ces corrections le 21 octobre 2026 dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les logiciels que vous avez installés par-dessus sont une autre affaire : le guide de sécurisation de WordPress indique que les hébergeurs s'occupent de l'infrastructure, mais ne sont pas responsables de l'application que vous choisissez d'installer. Ce guide est à jour au 23 octobre 2026.

Réponse rapide

Le correctif de votre hébergeur couvre PHP sur ses serveurs. Sur votre compte, mettez à jour WordPress ou votre CMS, avec ses extensions et ses thèmes. Vérifiez la version de PHP de chacun de vos sites, car cPanel permet une version par domaine. Cherchez des signes de compromission, comme le conseille le NCSC britannique, et changez vos mots de passe si quelque chose semble anormal.

Que couvre le correctif PHP de mon hébergeur ?

PHP lui-même. L'avis PHP du 21 octobre 2026 indique que deux failles, CVE-2026-109618 et CVE-2026-109619, touchent toutes les installations de PHP qui répondent à des requêtes web et peuvent permettre une exécution de code à distance sans authentification. Autrement dit, quelqu'un pourrait faire tourner son propre code sur le serveur sans se connecter. L'avis cite PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed, tous des logiciels de serveur : sur un hébergement mutualisé ou infogéré, cette mise à jour revient donc à votre hébergeur.

Le correctif ne met à jour ni WordPress, ni un thème, ni une extension. Ils ont leurs propres mises à jour.

Sur l'exploitation, au 23 octobre 2026 : l'agence américaine CISA indique, dans son alerte du 21 octobre révisée le 23 octobre, ne pas avoir observé d'exploitation réussie de ces vulnérabilités en conditions réelles au moment de la publication, et le CERT-FR, l'équipe de réponse aux incidents de l'ANSSI, a ajouté le 22 octobre qu'il a connaissance de preuves de concept pour des déploiements spécifiques de PHP. L'avis PHP juge le risque le plus élevé pour Apache avec mod_php, avec un exploit démontré où une requête non authentifiée peut déclencher l'attaque avant l'exécution de tout code de l'application.

Dois-je quand même mettre à jour WordPress, les extensions et les thèmes ?

Oui. Le guide de sécurisation de WordPress demande de toujours rester à jour avec la dernière version de WordPress, et précise que les anciennes versions ne reçoivent plus de mises à jour de sécurité. Il donne le même conseil pour les extensions, et recommande de supprimer celles que vous n'utilisez pas. Faites d'abord une sauvegarde, comme le suggère le guide de mise à jour de WordPress.

Connectez-vous à l'administration et allez dans Tableau de bord > Mises à jour.
Si une nouvelle version de WordPress est proposée, cliquez sur le bouton Mettre à jour vers la version indiquée.
Sur le même écran, cochez les extensions et les thèmes qui ont une mise à jour, puis cliquez sur Mettre à jour les extensions ou Mettre à jour les thèmes. La case en haut de chaque section sélectionne tout.
Allez dans Extensions > Extensions installées et supprimez celles dont vous ne vous servez plus.

WordPress indique que la plupart des sites appliquent désormais automatiquement ses versions mineures et de sécurité, mais qu'une version majeure demande encore votre clic.

Sur quelle version de PHP mon site tourne-t-il vraiment ?

Vérifiez au lieu de supposer. La documentation de cPanel indique que chaque domaine peut utiliser n'importe quelle version de PHP installée : la version corrigée par votre hébergeur et celle de chacun de vos sites méritent donc d'être confirmées séparément. Notre guide pour vérifier la version de PHP de votre site montre où regarder dans WordPress et dans cPanel. Si un site est sur une version plus ancienne, mettre à jour PHP sur WordPress explique comment en changer. PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet PHP : un site sur l'une d'elles demande une discussion avec votre hébergeur, et notre guide sur la fin de support de PHP 8.1 présente les options.

Dois-je chercher des signes de compromission ?

Oui, s'il y a eu un délai avant le correctif. Le NCSC britannique demande à ceux qui ne peuvent pas mettre à jour ou désactiver un système tout de suite d'y chercher des traces de compromission avant la mise à jour ou l'atténuation, notamment des portes dérobées. Une version de PHP plus récente corrige la faille. Elle ne vous dit pas si quelque chose s'est passé avant.

Allez dans Comptes > Tous les comptes et cliquez sur le lien Administrateur/administratrice au-dessus du tableau. La FAQ de WordPress sur les sites piratés cite la création de nouveaux comptes comme un signe clair.
Ouvrez le rapport sur les problèmes de sécurité dans la Google Search Console. Google indique qu'il signale si votre site a été piraté ou s'il peut nuire aux visiteurs.
Demandez à votre hébergeur s'il a repéré quelque chose sur votre compte.

Notre guide sur les signes d'un site WordPress piraté détaille chaque vérification.

Quand changer mes mots de passe ?

Tout de suite si quelque chose semble anormal. La FAQ de WordPress demande de changer chaque point d'accès, qu'elle liste ainsi : FTP ou SFTP, l'administration WordPress, cPanel ou tout autre panneau d'hébergement, et la base de données, pour chaque personne qui y a accès, pas seulement vous. Site piraté : que faire donne l'ordre des étapes.

Que demander à mon hébergeur ?

Des questions courtes et factuelles obtiennent les réponses les plus utiles.

Sur quelle version de PHP tourne chacun de mes sites aujourd'hui, et est-ce 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ?
Si l'un de mes domaines est réglé sur Inherited (hérité), quelle est la version par défaut du serveur ?
Si un site est en PHP 8.1 ou plus ancien, avez-vous appliqué un correctif rétroporté ? Le projet PHP indique que certains fournisseurs en proposent.
Avez-vous réglé session.upload_progress.enabled=0, comme le suggère l'avis d'information de PHP du 23 octobre jusqu'à la prochaine version corrective ?
Avez-vous vu quoi que ce soit sur mon compte, ou sur le serveur que je partage, qui fasse penser à une compromission ? La FAQ de WordPress indique qu'un piratage sur un hébergement mutualisé peut toucher plus d'un site.
Quelles sauvegardes de mon site conservez-vous ? WordPress suggère d'interroger votre hébergeur sur sa politique de sauvegarde.

Autres questions

Mon hébergeur est-il touché par PHP2Shell ?

S'il fait tourner PHP pour servir des sites, il l'était jusqu'à sa mise à jour. Le NCSC britannique indique que les organisations qui utilisent n'importe quelle version de PHP sont concernées, et la CISA que PHP est souvent un composant d'autres logiciels. Notre guide faille PHP PHP2Shell présente les failles.

Mon hébergeur a corrigé PHP. Mon site est-il sûr maintenant ?

Les deux failles sont corrigées dans les versions mises à jour. Le guide de sécurisation de WordPress rappelle aussi que sur un serveur partagé, votre site peut être compromis à son tour si un autre site du serveur l'est. Vos propres mises à jour, la vérification de version et la recherche de compromission restent utiles.

Un pare-feu applicatif web fait-il le même travail que le correctif ?

Non. L'avis PHP dit que seule la mise à jour est une solution complète. Notre guide pour tester votre site contre la faille PHP détaille ce qu'un pare-feu peut apporter en attendant.

De quoi parlait l'avis PHP du 23 octobre ?

D'une voie d'exécution de code à distance distincte et peu probable, CVE-2026-115560. PHP indique qu'elle demande une combinaison inhabituelle de configuration et de code applicatif, et suggère de régler session.upload_progress.enabled=0 jusqu'à la prochaine version corrective. Ce réglage se fait sur le serveur, donc par votre hébergeur.

Mon site doit-il être mis hors ligne en attendant le correctif ?

Le CERT-FR recommande d'isoler les équipements sous des versions non maintenues avant de migrer. Le NCSC conseille d'envisager la mise hors ligne d'un système qui ne peut pas être mis à jour ou protégé rapidement, et la CISA de mettre hors ligne les systèmes PHP qui ne peuvent pas être mis à jour tout de suite ou qui tournent encore sous PHP 8.1 ou plus ancien. Une fois votre site confirmé sur une version corrigée, ce conseil ne s'applique plus à lui.