En bref : face à une faille PHP comme PHP2Shell, c'est l'hébergeur, et non vous, qui est responsable de la mise à jour de PHP en hébergement web. Votre rôle est d'obtenir une confirmation écrite, de choisir dans l'espace client une version de PHP prise en charge et de rechercher sur votre site des traces d'une attaque. Un correctif de l'hébergeur ne supprime pas les logiciels malveillants arrivés auparavant sur votre site.
La situation en termes simples
PHP est le langage de programmation sur lequel fonctionnent la plupart des sites, boutiques et CMS comme WordPress. PHP2Shell désigne deux erreurs critiques dans PHP lui-même (CVE-2026-109618 et CVE-2026-109619). Des attaquants peuvent ainsi exécuter leur propre code sur le serveur sans mot de passe. Le BSI (office fédéral allemand de la sécurité des technologies de l'information) a déclenché le niveau d'alerte 3 (orange) et recommande une mise à jour immédiate.
En hébergement mutualisé, de nombreux clients se partagent un serveur. L'hébergeur exploite l'infrastructure sous-jacente, c'est-à-dire le système d'exploitation, le serveur web et PHP. Vous gérez uniquement votre site, votre base de données et vos accès. C'est pourquoi vous ne pouvez pas installer vous-même la mise à jour de PHP, et vous n'avez pas à le faire.
Hébergement web et faille PHP : qui est responsable ?
La répartition découle de votre contrat. Dans la plupart des offres, elle se présente globalement ainsi :
| Tâche | Hébergeur | Vous en tant que client |
|---|---|---|
| Mettre à jour les paquets PHP | oui | non |
| Redémarrer les processus PHP | oui | non |
| Définir des valeurs transitoires pour tout le serveur | oui | non |
| Choisir la version de PHP de votre site | la met à disposition | choisit |
| Mettre à jour CMS, extensions, thèmes | non | oui |
| Identifiants et comptes administrateur | non | oui |
| Rechercher du code malveillant sur le site | en partie | oui |
| Évaluation au regard de la protection des données | non | oui |
La dernière ligne est importante : si un incident impliquant des données personnelles survient sur votre site, c'est en général vous, en tant qu'exploitant, qui êtes responsable, et non l'hébergeur. Plus de détails sous Obligation de notification RGPD.
Ce que vous devriez faire dès maintenant
1. Obtenir une confirmation. Demandez par écrit à votre hébergeur si les versions de PHP de votre offre sont protégées contre les deux CVE, depuis quand, et si tous les processus PHP ont été redémarrés. Vous trouverez un modèle prêt à l'emploi sous Demander à l'hébergeur l'état du correctif. Ne vous étonnez pas si l'espace client continue d'afficher un ancien numéro de version comme 8.2.34 : certains fournisseurs livrent les corrections sous forme de backport sans que le numéro change.
2. Vérifier la version de PHP. Consultez dans l'espace client la version de PHP utilisée par votre site. PHP 8.1 et antérieur ne reçoivent plus de mises à jour officielles du projet PHP. PHP 8.2 atteint la fin de son support le 31 décembre 2026. Pour savoir si votre CMS supporte une version plus récente, reportez-vous à la configuration requise indiquée par l'éditeur, par exemple sur wordpress.org.
3. Contrôler le site. Soyez attentif aux comptes administrateur inconnus, aux redirections inattendues, aux fichiers étrangers dans l'accès FTP et aux avertissements dans Google Search Console. Une liste de signes typiques figure sous Suis-je déjà compromis ?.
4. Créer une sauvegarde. Téléchargez une sauvegarde récente des fichiers et de la base de données et conservez-la séparément. Demandez en outre à l'hébergeur de conserver les journaux d'accès de votre offre à partir du 20 octobre 2026.
Une fois la confirmation de l'hébergeur obtenue, changez par précaution les mots de passe de l'espace client, du FTP/SFTP, de la base de données et des administrateurs du CMS, et activez l'authentification à deux facteurs là où c'est possible.
Ce que vous ne pouvez pas résoudre vous-même en hébergement mutualisé
Les mesures transitoires recommandées par php.net, par exemple session.upload_progress.enabled=0, ne fonctionnent que si elles sont définies dans la configuration du serveur. Selon php.net, une entrée dans .user.ini ou via ini_set() dans le code ne suffit pas. Les limites de mémoire au niveau des cgroups et le redémarrage des processus PHP relèvent eux aussi de l'hébergeur.
Si votre hébergeur ne répond pas ou répond de façon évasive, vous avez trois possibilités : relancer en fixant un délai, mettre le site temporairement en mode maintenance ou passer chez un fournisseur qui s'exprime clairement. Le BSI recommande de déconnecter temporairement les serveurs web du réseau lorsqu'une mise à jour n'est pas possible immédiatement.
Vérifiez aussi si votre offre est encore adaptée. Les offres qui tournent sans changement depuis de nombreuses années se trouvent parfois sur d'anciennes générations de serveurs avec d'anciennes versions de PHP que l'hébergeur ne maintient plus que de façon limitée. Passer à une offre actuelle du même fournisseur demande souvent peu d'efforts et apporte des versions de PHP plus récentes. Posez la question si la réponse sur l'état du correctif n'est pas satisfaisante.
Si le site présente déjà des anomalies
Un correctif chez l'hébergeur ferme la faille pour l'avenir. Il ne supprime pas une porte dérobée que des attaquants ont installée auparavant et ne prouve pas que rien ne s'est produit. Si vous constatez des anomalies, ne supprimez pas des fichiers au hasard. Sauvegardez d'abord l'état du système, afin que la cause reste compréhensible par la suite.
Comment PHP SOS aide-t-il concrètement ?
- Nous rédigeons avec vous la demande à l'hébergeur et évaluons sa réponse sur le plan technique.
- Nous examinons votre site à la recherche de webshells, de comptes étrangers et de fichiers manipulés et, en cas de constat, nous le nettoyons grâce à notre suppression des logiciels malveillants.
- En cas de soupçon aigu, nous assurons l'assistance d'urgence pour les sites piratés, avec préservation des preuves.
- Nous vous aidons à choisir une version de PHP adaptée et testons ensuite le site.
Questions fréquentes
En tant que client d'un hébergeur, dois-je mettre PHP à jour moi-même ?
En général non, car en hébergement mutualisé, PHP fait partie de la plateforme de l'hébergeur. Vous pouvez toutefois souvent choisir la version de PHP dans l'espace client. Si la version indiquée ne reçoit plus de mises à jour officielles, changez de version ou demandez à l'hébergeur comment il la protège.
Mon site est hors ligne. Ai-je été piraté ?
Pas forcément. Certains fournisseurs ont mis des sites hors ligne à titre préventif pour combler la faille. Demandez la raison à l'hébergeur et faites-vous confirmer s'il existe des indices d'une attaque contre votre offre.
Puis-je définir moi-même les mesures transitoires dans .user.ini ?
Pour session.upload_progress.enabled, php.net précise expressément que .user.ini et ini_set() ne suffisent pas. Ce paramètre doit être défini par l'hébergeur dans la configuration du serveur.
Que dois-je obtenir par écrit de l'hébergeur ?
Une confirmation que les versions de PHP de votre offre sont protégées contre CVE-2026-109618 et CVE-2026-109619, à partir de quand, et que les processus PHP ont été redémarrés. Conservez cette réponse avec vos documents.