Plusieurs sites infectés sur le même compte d'hébergement

Ce que « même compte » veut dire concrètement

Plusieurs sites infectés sur le même compte d’hébergement, ce n’est pas de la malchance statistique. C’est souvent le même utilisateur système, le même PHP qui peut `fopen` le dossier d’à côté, les mêmes mots de passe FTP, le même cron. « Mutualisé » chez l’hébergeur, « un login cPanel » chez vous : un home, plusieurs document roots.

Infection latérale : le site B (vieux Joomla, préprod oubliée) écrit dans `../siteA/wp-content/uploads`. Votre Wordfence sur A est vert après nettoyage. B n’a pas de plugin. H+6, A est sale. Vous accusez WordPress. C’était B.

Listez d’abord : domaines, sous-domaines, addon, alias, dossiers `public_html`, `www`, `old`, `backup`, `dev`. Le gestionnaire de fichiers, pas seulement « mes sites » dans la tête. On trouve toujours un dossier de plus.

• Un user Unix / un cPanel = un périmètre.
• Le site « important » n’est pas le seul à inspecter.
• Les archives zip dans le home sont des sites potentiels (et des secrets).

Comment l’infection circule d’un dossier à l’autre

PHP du site B avec les droits de l’utilisateur : lecture `wp-config` de A, écriture d’un mu-plugin chez A. Cron qui boucle sur tous les `*/public_html`. Mot de passe FTP unique pour tout le compte. Panel : un attaquant qui a le panel n’a pas besoin de « circuler », il est déjà partout.

Moins fréquent mais réel : inclusion via un mauvais `open_basedir`, un `symlink`, un plugin de backup qui zippe tout le home dans un dossier web de A (et le zip se télécharge). Le vecteur n’est pas magique. Il est local.

Les scanners « un site = une licence » ne marchent pas ce problème. Ils n’ont pas le droit, parfois, de sortir du document root. Croyez leur vert sur A, c’est leur scope, pas la vérité du compte.

Le site abandonné, cas le plus fréquent

Campagne 2018, préprod `dev.exemple.fr`, `exemple.fr/old`, un PrestaShop mort, un WordPress d’essai. Plus à jour depuis des années, parfois encore dans le DNS. C’est la rampe. On ne le « nettoie » pas : on l’éteint (vhost, DNS, dossier hors web), après copie s’il reste une pièce, ou on le traite comme un incident à part s’il doit vivre.

Tant qu’il répond 200 avec un CMS troué, il refera A. Les titulaire disent « on s’en sert plus donc ce n’est pas grave ». C’est l’inverse : plus personne ne le regarde, donc personne ne voit le shell.

Parked / addon oublié : même famille. Voir aussi sous-domaine oublié et parked domain.

Ce que le plugin du site A ne voit jamais

Le document root de B, les crons du compte, les mails, les autres bases SQL du même user, le `~/tmp` , le `~/.ssh`. Wordfence n’est pas l’antivirus du cPanel. Ne lui demandez pas ça. Plugin pendant l’attaque.

L’hébergeur, lui, scanne parfois tout le home. D’où un email « malware » sur un chemin que vous ne reconnaissez pas : ce n’est pas « une erreur ». C’est B. Demandez le chemin, ouvrez B.

Un seul site « vert » dans un compte sale n’est pas un indicateur. C’est un angle mort.

Ordre de nettoyage : cartographier d’abord

Inventaire écrit : domaine → dossier → CMS → dernier admin humain → on garde / on éteint. Puis copie du home (ou de chaque vhost). Puis secrets panel (une fois, ça couvre tout). Puis traitement des rampes (éteindre B) avant le polish de A, ou en parallèle. Nettoyer A trois fois pendant que B tourne est du temps perdu.

Si le temps manque : éteindre B (403, retirer le vhost, dossier hors web) le jour J, nettoyer A le soir. Mieux qu’un A « nickel » et un B ouvert.

Bases : une base par site, parfois une base partagée. Une injection dans une table n’est pas « le problème de A seulement » si l’user SQL voit les deux.

Permissions, PHP, et cage qui n’en est pas une

Sur un bon mutualisé, `open_basedir` empêche A de lire B. Sur un mauvais, ou un VPS « tout en 755 », non. Après incident : demandez à l’hébergeur l’isolation, vérifiez qu’un PHP de B ne fait pas file_get_contents vers le wp-config de A. Si ça passe, changez d’offre ou d’hébergeur — après nettoyage, voir migrer propre.

Permissions : `wp-config` 600, pas 644 si l’user est partagé. Les backups du home ne doivent pas être dans un dossier web. Les zips `backup-tous-mes-sites.zip` à la racine de A sont une fuite + une rampe.

Un FTP par site, pas un FTP sur `public_html` entier. Plus pénible. Moins de latéral.

Un seul ticket abuse, plusieurs vhosts

L’hébergeur suspend le compte, pas « la boutique ». Votre constat doit lister tous les chemins, y compris B. « A est propre » alors que le scan voit B : refus. Répondre à l’abus : tableau domaine / trouvé / retiré.

Ne créez pas un ticket par site. Un fil, une référence, l’inventaire. Sinon quatre interlocuteurs et un unsuspend partiel.

Resource abuse (minage) : le process est souvent sur B. Tuez le cron du compte, pas seulement le plugin de A.

Pour que ça ne revienne pas par le voisin

Éteindre les morts, séparer les FTP, isolation, mots de passe distincts, ne plus empiler vingt sites « on ne sait jamais ». Un site = une raison d’être encore en 200. Surveillance des dates sur tout le home, pas un scan A le lundi.

Si vous ne pouvez pas gérer quinze CMS, vous n’avez pas quinze CMS. Vous avez une surface. Réduisez-la. C’est plus efficace qu’un WAF sur A seul.

Guide voisin de serveur pour l’IP partagée avec d’autres clients. Ici, le voisin, c’était vous.