# PHP2Shell : 15 questions de clients d'hébergeurs > Faille PHP et hébergement : 15 questions de clients d'hébergeurs sur PHP2Shell, avec réponses brèves sur la responsabilité, la preuve et les cas suspects. Source : https://phpsos.de/fr/blog/fragen-von-hosting-kunden/ État : 25/10/2026 Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6 **En bref :** que faire en tant que client d'un hébergeur face à la faille PHP2Shell ? Vous n'avez le plus souvent pas à installer vous-même la mise à jour de PHP : en hébergement mutualisé, c'est l'hébergeur qui s'en charge. Vos tâches sont autres : obtenir une confirmation écrite du niveau de correctif, choisir dans l'espace client une version de PHP prise en charge et vérifier votre site à la recherche d'anomalies. Cet article répond brièvement et dans l'ordre aux 15 questions les plus fréquentes. ## Faille PHP en tant que client d'un hébergeur : suis-je concerné, que faire ? Depuis le 21 octobre 2026, nous recevons de nombreuses questions d'entreprises dont le site est chez un hébergeur. La plupart tournent autour des mêmes points. Qui souhaite lire plus en détail sur les responsabilités les trouvera sous [Hébergement mutualisé : ce que fait l'hébergeur et ce que vous devez faire](https://phpsos.de/fr/server/shared-hosting/). ### 1. Mon site est-il seulement concerné ? Si votre site fonctionne avec WordPress, Shopware, TYPO3, Joomla, Contao ou un autre système PHP, le serveur qui le porte est peut-être concerné. Les pages HTML pures sans PHP ne le sont pas. Dans le doute, un coup d'œil à l'espace client aide : s'il y existe un paramètre pour la version de PHP, vous utilisez PHP. ### 2. Quelle est la différence entre hébergement mutualisé et serveur dédié ? En hébergement mutualisé, vous partagez avec d'autres clients un serveur exploité par l'hébergeur ; l'hébergeur entretient PHP. Avec votre propre serveur root ou vServer, vous êtes vous-même responsable. Avec un serveur géré, le contrat règle qui installe les mises à jour. ### 3. Mon hébergeur a envoyé un e-mail collectif. Dois-je encore faire quelque chose ? Lisez attentivement ce qu'il contient. Un e-mail collectif confirme souvent seulement que l'hébergeur « travaille sur le sujet ». Il vous faut une déclaration sur votre formule : branche PHP, niveau de correctif, date et redémarrage. ## Responsabilité et mise à jour ### 4. L'hébergeur installe-t-il la mise à jour automatiquement ? En règle générale oui, pour les versions de PHP qu'il propose sur ses serveurs. Savoir si c'est déjà fait et si d'anciennes versions sont aussi couvertes varie d'un hébergeur à l'autre. Posez la question. ### 5. Mon espace client affiche un ancien numéro de version. Suis-je sans protection ? Pas nécessairement. De nombreux hébergeurs intègrent les corrections sous forme de rétroportage, le numéro reste alors le même. Plesk, par exemple, peut continuer d'afficher 8.2.34 alors que l'erreur est corrigée. La confirmation de l'hébergeur fait foi. ### 6. J'utilise encore PHP 7.4 ou 8.1. Que faire ? Ces branches ne reçoivent plus de mises à jour officielles du projet PHP. Certains hébergeurs fournissent leurs propres corrections, d'autres non. Clarifiez cela par écrit et planifiez le passage à une branche prise en charge. Vérifiez au préalable dans la configuration requise de votre CMS quelles versions de PHP il prend en charge. ### 7. Puis-je changer moi-même la version de PHP ? Chez la plupart des hébergeurs oui, dans l'espace client. La manière de procéder et ce qu'il faut vérifier au préalable sont décrits dans l'article [Modifier la version de PHP dans l'espace client de l'hébergeur](https://phpsos.de/fr/blog/php-version-hosting-aendern/). Faites d'abord une sauvegarde. ### 8. Mettre à jour WordPress ou les plugins aide-t-il ? Pas contre PHP2Shell, car la faille se trouve dans PHP. Les mises à jour du CMS restent utiles, car elles corrigent d'autres failles. ## Vérifier et prouver ### 9. Comment obtenir une preuve de l'hébergeur ? Par une demande écrite exigeant des indications concrètes : niveau des paquets pour chaque branche PHP, date d'installation, redémarrage de tous les processus PHP. Un modèle à copier figure dans le guide [Demander à l'hébergeur la confirmation de la mise à jour PHP](https://phpsos.de/fr/ratgeber/hoster-patch-status-erfragen/). ### 10. Puis-je appliquer des mesures transitoires via .user.ini ? Non. php.net déconseille expressément de définir les paramètres transitoires via `ini_set()` ou `.user.ini`. Ils relèvent de la configuration du serveur, que l'hébergeur gère en hébergement mutualisé. ### 11. Mon site a été brièvement hors ligne. Ai-je été piraté ? Pas forcément. Certains hébergeurs ont mis des sites hors ligne par précaution ou redémarré des serveurs. Demandez la raison avant de tirer des conclusions. ### 12. À quoi reconnais-je que mon site a été attaqué ? Des indices possibles sont des comptes administrateur inconnus, de nouveaux fichiers PHP dans le dossier d'envoi, des redirections vers d'autres sites, des pages étrangères dans l'index de Google ou des avertissements dans la Search Console. Demandez à l'hébergeur de conserver les journaux d'accès à partir du 20 octobre. ## Si quelque chose ne va pas ### 13. L'hébergeur ne répond pas ou répond évasivement. Que faire ? Demandez par écrit et fixez un délai raisonnable. En l'absence de réponse, vous devriez considérer le serveur comme non vérifié et envisager de basculer temporairement le site sur une page d'urgence statique. ### 14. Dois-je changer d'hébergeur ? Un changement en pleine situation crée ses propres risques. Il se justifie si l'hébergeur ne donne durablement aucune information ou continue d'exploiter d'anciennes versions de PHP sans correction. Ce qu'il faut observer alors est décrit dans [Changer d'hébergeur après un incident](https://phpsos.de/fr/blog/hoster-wechseln-nach-vorfall/). ### 15. Dois-je signaler quelque chose ? S'il existe des indices d'une attaque et que des données personnelles peuvent être concernées, une obligation de notification au titre du RGPD peut exister, en règle générale dans un délai de 72 heures. Clarifiez cela avec votre délégué à la protection des données ou un avocat. Ceci n'est pas un conseil juridique. ## Votre liste de contrôle rapide 1. Demander par écrit à l'hébergeur le niveau de correctif et le redémarrage. 2. Vérifier la version de PHP dans l'espace client, remplacer les branches obsolètes. 3. Passer en revue les comptes administrateur et le dossier d'envoi. 4. Consulter la Search Console pour des avertissements. 5. En cas d'anomalies, chercher de l'aide avant de supprimer des fichiers. ## Comment PHP SOS aide-t-il concrètement ? - **Clarification avec l'hébergeur :** nous rédigeons la demande ou menons l'échange et évaluons la réponse. - **Vérification du site :** nous recherchons des traces dans les fichiers, la base de données et les comptes, dans la mesure où l'offre d'hébergement le permet. - **Nettoyage :** si nous trouvons du code malveillant, nous le supprimons et changeons tous les accès. - **Documentation :** vous recevez l'état par écrit. En cas de soupçon concret, l'[assistance d'urgence pour sites piratés](https://phpsos.de/fr/leistungen/website-gehackt-notfallhilfe/) vous aide. ## Conclusion En tant que client d'un hébergeur, vous ne portez pas, avec PHP2Shell, la charge de la mise à jour, mais la responsabilité de votre site. La plupart des questions se règlent avec une réponse écrite claire de votre hébergeur. Ce qui reste ensuite, c'est le regard sur votre propre site : comptes, fichiers, avertissements de Google. Qui a fait les deux a rempli sa part et peut, dans le doute, prouver qu'il a agi avec soin. ## Questions fréquentes **Qui est responsable de la mise à jour de PHP en hébergement web ?** En hébergement mutualisé, en règle générale l'hébergeur, car il exploite le serveur et l'installation de PHP. Vous êtes responsable de votre site, de vos accès et du choix de la version de PHP dans l'espace client. Pour les serveurs gérés, le contrat règle la répartition. **Pourquoi mon hébergeur affiche-t-il une ancienne version de PHP ?** De nombreux hébergeurs et distributions intègrent la correction sous forme de rétroportage dans la version existante. Le numéro reste alors le même alors que la faille est corrigée. Fiez-vous donc à une confirmation écrite de l'hébergeur, non à l'affichage. **Que puis-je vérifier moi-même en tant que client d'un hébergeur ?** Vous pouvez contrôler la version de PHP configurée dans l'espace client, passer en revue les comptes administrateur de votre CMS, rechercher des fichiers inconnus dans le dossier d'envoi (uploads) et consulter la Search Console pour des avertissements. Seul l'hébergeur peut prouver le niveau de correctif du serveur lui-même. **Un paramètre de pare-feu dans l'offre d'hébergement aide-t-il ?** Les règles de pare-feu de l'hébergeur ou d'un service placé en amont peuvent réduire le risque. Elles ne remplacent toutefois pas la mise à jour de PHP sur le serveur. Demandez donc toujours d'abord la mise à jour. ## Sources - [php.net : avis de sécurité](https://www.php.net/) - [PHP : versions prises en charge](https://www.php.net/supported-versions.php) - [Aide Google Search Console](https://support.google.com/webmasters/) - [RGPD art. 33 : notification à l'autorité de contrôle](https://dsgvo-gesetz.de/art-33-dsgvo/)