Mon hébergeur signale un malware ou suspend mon site WordPress : que faire ?

Votre hébergeur vient de signaler un fichier malveillant, de bloquer les e-mails envoyés par PHP ou de suspendre votre site WordPress ? Même si le site semble encore fonctionner, cette alerte doit être prise au sérieux. Elle indique qu’un comportement anormal a été détecté, mais elle ne permet pas toujours d’identifier immédiatement toute l’infection ni sa cause.

Le fichier mentionné dans le message peut être l’origine du problème, l’une de ses conséquences ou simplement le premier élément repéré par le système de détection. Une compromission peut aussi concerner la base de données, un compte administrateur, une tâche planifiée, une extension vulnérable ou des identifiants exposés.

La priorité n’est donc pas de supprimer au hasard ce qui paraît suspect. Il faut d’abord conserver les informations utiles, mesurer l’impact sur le site et éviter les manipulations susceptibles d’effacer des traces ou de provoquer une nouvelle panne.

Ce guide vous explique comment réagir à une alerte hébergeur concernant un malware WordPress, quelles vérifications effectuer sans aggraver la situation et quand demander un diagnostic de site WordPress piraté.

Pourquoi votre hébergeur vous envoie-t-il cette alerte ?

Un hébergeur surveille son infrastructure, les ressources consommées et certains comportements susceptibles de présenter un risque. Selon le prestataire et l’offre utilisée, son message peut correspondre à plusieurs situations.

Un fichier suspect ou malveillant a été détecté

L’alerte peut indiquer un chemin précis dans une extension, un thème, le répertoire des médias ou la racine du site. Cette information est importante, mais elle ne prouve pas que le fichier est le seul élément compromis.

Il peut avoir été ajouté après l’exploitation d’une faille, modifié à partir d’un compte compromis ou utilisé comme mécanisme permettant de revenir sur le site. À l’inverse, une détection automatique peut parfois nécessiter une vérification manuelle avant de conclure définitivement que le fichier est malveillant.

Des e-mails anormaux sont envoyés depuis l’hébergement

Un script PHP peut être utilisé pour envoyer du spam, des messages frauduleux ou un volume inhabituel d’e-mails. L’hébergeur peut alors limiter ou bloquer l’envoi afin de protéger son infrastructure et sa réputation.

Le problème peut provenir de WordPress, d’un formulaire détourné, d’une extension compromise, d’un script indépendant du CMS ou d’un accès technique exposé. Le blocage des e-mails PHP est donc un signal sérieux, mais il ne permet pas à lui seul d’identifier le script responsable ni la méthode utilisée pour l’installer.

Une activité technique est considérée comme dangereuse

Le prestataire peut observer des requêtes inhabituelles, l’exécution répétée d’un script, une consommation anormale de ressources ou des tentatives d’envoi massives. Selon la situation, il peut mettre un fichier en quarantaine, restreindre certaines fonctions, bloquer les e-mails ou suspendre temporairement l’hébergement.

Une suspension sert d’abord à limiter l’incident

La suspension ne signifie pas nécessairement que l’hébergeur connaît déjà l’origine complète du piratage. Il s’agit souvent d’une mesure de confinement destinée à stopper le comportement détecté.

Obtenir la remise en ligne ne suffit donc pas. Si le compte compromis, la vulnérabilité initiale ou le mécanisme de persistance sont toujours présents, le problème peut reprendre après la réactivation.

Distinguer le fait constaté de la cause supposée

Pour interpréter correctement le message, séparez toujours trois niveaux d’information :

• Fait constaté : un fichier a été mis en quarantaine à une date précise.
• Cause probable : un script semble avoir envoyé des messages non sollicités.
• Hypothèse à confirmer : l’accès initial pourrait provenir d’une extension vulnérable ou d’un identifiant compromis.

Cette distinction évite de transformer un indice en certitude et permet d’orienter plus efficacement le diagnostic.

Les informations à conserver avant toute intervention

La première action utile consiste à documenter précisément l’incident. Ces éléments permettront de reconstituer la chronologie, de comprendre ce que l’hébergeur a détecté et d’éviter de recommencer des contrôles déjà réalisés.

• le message complet envoyé par l’hébergeur ;
• la référence du ticket ou de l’incident ;
• la date, l’heure et le fuseau horaire de la détection ;
• les chemins des fichiers signalés ;
• le nom de la menace, de la signature ou de la règle de détection ;
• les actions appliquées : quarantaine, restriction, blocage des e-mails ou suspension ;
• des captures de l’e-mail et de l’espace client ;
• l’état du site et du back-office au moment du signalement ;
• le fonctionnement des formulaires, commandes, paiements ou réservations ;
• les mises à jour, installations et interventions réalisées récemment ;
• les dates des sauvegardes disponibles ;
• les journaux d’accès et d’erreurs encore accessibles.

Vérifiez aussi que le message reçu est authentique. En cas de doute, ouvrez directement l’espace client de votre hébergeur depuis votre navigateur au lieu d’utiliser le lien contenu dans l’e-mail.

Comment qualifier le niveau d’urgence ?

Toutes les alertes doivent être examinées, mais elles ne présentent pas le même niveau de criticité. L’impact sur les visiteurs, les données et l’activité doit guider la réaction.

Niveau	Exemples	Réaction recommandée
Critique	Page de phishing active, redirection vers un autre domaine, boutique potentiellement compromise, site suspendu, paiements ou données clients susceptibles d’être concernés	Limiter l’exposition et faire qualifier immédiatement l’incident
Élevé	Fichiers infectés signalés, e-mails PHP bloqués, administrateur inconnu, alertes répétées ou activité anormale confirmée	Préserver les informations et lancer un diagnostic prioritaire
À vérifier rapidement	Alerte isolée, fichier ancien mis en quarantaine ou site apparemment normal	Ne pas ignorer le signal et confirmer le périmètre avant de conclure

Un site accessible n’est pas nécessairement sain

Certaines infections ne se déclenchent que pour les visiteurs venant de Google, les utilisateurs mobiles, les internautes non connectés ou certaines zones géographiques. D’autres utilisent l’hébergement pour envoyer des e-mails ou créer des pages parasites sans modifier la page d’accueil.

Si vous observez une redirection, une alerte de sécurité, des pages inconnues dans Google ou des comptes non autorisés, consultez également le guide Site WordPress piraté : que faire ?.

Ce que vous pouvez faire sans aggraver la situation

Vérifier l’état réel des services

Testez séparément la page d’accueil, quelques pages stratégiques, l’administration WordPress, les formulaires, les e-mails transactionnels et, le cas échéant, les commandes ou réservations. Notez précisément ce qui fonctionne et les messages d’erreur visibles.

En présence d’une page de phishing ou d’une redirection malveillante, évitez toutefois de multiplier les visites depuis vos postes habituels. L’objectif est de confirmer le symptôme sans augmenter inutilement l’exposition.

Geler les changements non indispensables

Suspendez temporairement les mises à jour, les déploiements, les installations d’extensions et les modifications sans rapport avec l’incident. Plus le site change avant le diagnostic, plus la chronologie devient difficile à reconstituer.

Préserver une copie lorsque cela est possible

Une sauvegarde ou un snapshot pris avant intervention peut servir de point de référence, même si cette copie contient l’infection. Elle doit être clairement identifiée comme potentiellement compromise, stockée séparément et exclue de toute restauration automatique en production.

Une sauvegarde n’est réellement utile que si sa date est connue, si elle comprend les fichiers et la base de données et si elle peut être restaurée.

Contrôler les accès depuis un appareil fiable

Lorsque la compromission devient probable, vérifiez les comptes WordPress, l’espace client de l’hébergeur, les accès SFTP ou SSH, les comptes des prestataires et les services externes connectés au site. Utilisez un appareil à jour et activez la double authentification lorsqu’elle est disponible.

Ne modifiez pas le mot de passe de la base de données sans mettre à jour la configuration utilisée par WordPress. Le site ne pourrait alors plus se connecter à sa base.

Les erreurs à éviter après une alerte malware

Supprimer uniquement le fichier signalé

Le fichier peut n’être que la partie visible du problème. Une porte dérobée, une tâche planifiée, un compte administrateur non autorisé, un autre fichier injecté ou du code malveillant dans la base de données peuvent subsister.

Restaurer immédiatement une sauvegarde

La sauvegarde peut déjà contenir l’infection. Même lorsqu’elle est saine, elle ne corrige pas automatiquement une extension vulnérable, un mot de passe compromis ou une mauvaise configuration. Une restauration sans traitement de la cause probable peut être suivie d’une nouvelle compromission.

Réinstaller WordPress par-dessus le site

Remplacer les fichiers du cœur ne supprime pas nécessairement les fichiers ajoutés, les injections dans wp-content, les modifications de la base de données, les utilisateurs non autorisés ou les tâches planifiées malveillantes.

Installer plusieurs plugins de sécurité en urgence

Un scanner peut fournir des indices, mais aucun outil unique ne couvre obligatoirement les fichiers, la base de données, les comptes, les journaux, les tâches planifiées et les traces visibles dans Google. Multiplier les plugins peut également créer des conflits ou modifier le site avant l’analyse.

Réactiver seulement le service bloqué

Si l’hébergeur a bloqué les envois PHP ou suspendu le site, ne cherchez pas uniquement à lever la restriction. Sans correction de l’activité qui a déclenché le blocage, celui-ci peut revenir et la réputation de l’hébergement ou du domaine peut continuer à se dégrader.

Lorsqu’une infection est confirmée, la remise en état doit s’inscrire dans une démarche complète de nettoyage de malware WordPress, suivie d’une sécurisation et de contrôles après intervention.

Pourquoi le fichier signalé n’est-il pas toujours toute l’infection ?

Une compromission WordPress peut laisser des traces dans plusieurs zones. Le scanner de l’hébergeur peut détecter une signature connue ou un comportement précis sans révéler tous les mécanismes permettant à l’infection de persister.

• fichiers du cœur de WordPress ;
• extensions, thèmes et extensions obligatoires ;
• répertoire des médias ;
• base de données et options WordPress ;
• comptes utilisateurs et sessions actives ;
• tâches planifiées WordPress ou serveur ;
• règles serveur et fichiers de configuration ;
• formulaires et mécanismes d’envoi d’e-mails ;
• pages parasites visibles uniquement par certains visiteurs ou par les moteurs de recherche.

Pour mieux comprendre les différentes formes d’infection, consultez également le guide Malware WordPress : symptômes, risques et nettoyage.

Ce qu’un diagnostic doit vérifier

Un diagnostic sérieux ne cherche pas seulement un « virus WordPress ». Il doit déterminer ce qui est confirmé, jusqu’où l’incident peut s’étendre et quelles actions sont prioritaires.

1. L’alerte de l’hébergeur : message exact, horodatage, fichiers cités, mesures appliquées et éventuel historique.
2. Les fichiers WordPress : intégrité du cœur, des extensions, des thèmes, des médias et des éléments récemment ajoutés ou modifiés.
3. La base de données : contenus injectés, options inhabituelles, scripts, redirections et utilisateurs.
4. Les comptes et les accès : administrateurs, comptes prestataires, sessions, mots de passe et protection renforcée.
5. Les tâches planifiées : événements WordPress, tâches serveur et mécanismes susceptibles de recréer un fichier supprimé.
6. Les journaux : requêtes, erreurs, connexions, exécutions PHP et envois d’e-mails.
7. Le fonctionnement métier : formulaires, commandes, paiements, réservations et messages transactionnels.
8. La visibilité externe : redirections, alertes navigateur, pages inconnues dans Google et données Search Console.
9. Les sauvegardes : dates, contenu, intégrité et possibilité réelle de restauration.
10. La cause probable : composant vulnérable, compte compromis, appareil infecté ou configuration insuffisamment protégée.

Le compte rendu doit distinguer les faits confirmés, les hypothèses raisonnables et les points qui ne peuvent pas être établis faute de journaux ou d’historique.

Les informations à transmettre pour accélérer la prise en charge

Une demande structurée permet d’évaluer plus rapidement le niveau de risque. Préparez les éléments suivants :

• l’URL du site ;
• le type de site : vitrine, WooCommerce, réservation, extranet ou autre ;
• le nom de l’hébergeur ;
• la copie complète de l’alerte ;
• la date du premier signal ;
• les chemins de fichiers mentionnés ;
• les mesures déjà prises par l’hébergeur ;
• l’état du site et de l’administration ;
• les symptômes observés ;
• les actions déjà tentées ;
• la date de la dernière sauvegarde connue ;
• l’impact sur les ventes, formulaires, réservations ou demandes de contact.

Ne joignez aucun identifiant au premier message. Les accès éventuels seront demandés séparément après qualification du besoin.

Questions fréquentes

Une alerte de l’hébergeur confirme-t-elle toujours un piratage ?

Elle confirme généralement qu’un événement ou un élément technique a été détecté. Elle ne suffit pas toujours à établir l’origine, l’ancienneté ou l’étendue complète de la compromission. Le message doit être rapproché des autres symptômes, des fichiers, des comptes, des journaux et des modifications récentes.

Puis-je supprimer le fichier indiqué dans l’e-mail ?

Pas avant d’avoir conservé les informations utiles et vérifié son rôle. Sa suppression peut être nécessaire s’il est malveillant, mais elle ne démontre pas que le site est sain. D’autres traces ou mécanismes de persistance peuvent subsister.

Dois-je restaurer immédiatement une sauvegarde ?

Non. Vérifiez d’abord sa date, son contenu et son intégrité. Une sauvegarde peut déjà être infectée. Même lorsqu’elle est saine, elle ne dispense pas de corriger le point d’entrée probable avant la remise en ligne.

Le site fonctionne encore : est-ce vraiment urgent ?

Oui, notamment si l’hébergeur a détecté un fichier, bloqué les envois ou observé une activité anormale. Une infection peut rester discrète, ne toucher que certains visiteurs ou utiliser l’hébergement sans rendre le site indisponible.

Que signifie un blocage des e-mails PHP ?

L’hébergeur a généralement limité une fonction d’envoi après avoir observé un comportement inhabituel, un volume excessif ou un risque de spam. Il faut identifier le script concerné et comprendre pourquoi il a envoyé ces messages. Le problème peut venir de WordPress, d’un formulaire, d’une extension ou d’un autre script.

Quels accès seront nécessaires pour le diagnostic ?

Un pré-diagnostic peut commencer avec l’URL, l’alerte et les symptômes. Une analyse complète peut ensuite nécessiter des accès temporaires à WordPress, à l’hébergement, au SFTP ou SSH, aux journaux, à la base de données ou à Google Search Console. Ils doivent être transmis séparément, limités au strict nécessaire puis modifiés ou révoqués après l’intervention.

Combien de temps prend la remise en état ?

La durée dépend de la suspension éventuelle, de la taille du site, des accès disponibles, du nombre de zones touchées, de la qualité des sauvegardes et de la complexité des fonctionnalités. Une première qualification permet d’évaluer le périmètre et les priorités avant de proposer les actions adaptées.