WordPress propre, voisin de serveur sale : le cas que Wordfence ne voit pas

Ce que le plugin de sécurité ne voit pas

Wordfence, Sucuri, iThemes : ils scannent les fichiers que le PHP du site a le droit de lire, en pratique « leur » arbre. Un `../autre-site/shell.php` qui fait `file_put_contents` chez vous n'apparaît pas dans leur rapport, ou apparaît trop tard, comme un fichier « modified » sans cause. Relancer un scan après chaque nettoyage sans lister les autres vhosts du panel, c'est recommencer.

Le symptôme côté WordPress est banal : mu-plugin qui revient, `index.php` retouché, user admin recréé. L'entrée n'est pas une CVE de plugin. C'est un user Unix partagé, un `open_basedir` trop large, un mauvais chmod, un script d'un addon domain.

Les premiers gestes restent valables (copie, panel, mots de passe). Ajoutez : liste complète des sites du compte avant de déclarer la prod propre.

Compte mutualisé, user Unix, open_basedir

Sur un mutualisé classique, plusieurs domaines partagent le même utilisateur système. Le PHP de A peut souvent lire le `wp-config` de B, parfois y écrire. `open_basedir` et des droits 750 sur les homes séparent les comptes d'abonnés différents — pas vos cinq sites entre eux. C'est vous l'isolation, ou un hébergeur qui vend des comptes séparés.

Demandez (ou testez avec mesure) si le PHP du site A voit `/home/xxx/autre-domaine/`. Si oui, un site abandonné est une rampe vers tous les autres. Les dossiers « on garde au cas où » sont des portes. Voir staging oublié et addon / parked.

SSH / FTP : un seul identifiant pour tout le compte. Le pirate qui a le FTP n'a pas « piraté WordPress ». Il a le disque. Tourner uniquement l'admin WP de la prod est insuffisant.

• Tous les domaines et sous-domaines du panel.
• Tous les users FTP / SSH du compte.
• Permissions de `wp-config.php` et des homes.

Comment le voisin écrit chez vous

Un webshell sur B parcourt les `wp-config`, pose un mu-plugin chez A, recrée un admin via wp-load. Variante : cron de B appelle un PHP qui écrit dans A. Variante : une sauvegarde de B extraite « à la racine du compte » mélange les arbres. Les dates de modification chez A collent à l'activité chez B, pas à un login wp-admin.

Les journaux FTP et les access.log de B datent mieux que ceux de A. Demandez-les pour tout le compte, pas pour « le » site. L'hébergeur comprend un ticket « suspicion d'écriture latérale, besoin des vhosts et des logs FTP ». Il comprend moins « Wordfence est vert, rouvrez ».

Inventaire du compte, pas du CMS

Pour chaque dossier web : quel CMS, quelle date de fichiers, y a-t-il un PHP isolé à la racine, un phpMyAdmin, un `installer.php`. Les sites morts se ferment (vhost + DNS + dossier hors web après archive). Les sites vivants se mettent à jour ou se nettoient. Pas de troisième voie « on verra ».

Un site statique HTML dans un sous-dossier peut quand même héberger un PHP déposé. L'absence de WordPress n'est pas une absence de surface.

Même IP, autre problème : la réputation

Même sans écriture latérale, vous partagez une IP. Un voisin (votre autre site, ou celui d'un autre abonné selon l'hébergeur) qui envoie du phishing noircit l'IP. Vos devis tombent en spam, parfois Safe Browsing se trompe de vhost. Le nettoyage local de A ne blanchit pas l'IP. Voir IP serveur blacklistée et le guide réputation IP.

Ne migrez pas A encore sale pour « changer d'IP ». Vous noircissez la suivante. Nettoyez le compte, puis, si l'IP reste listée et que l'hébergeur ne peut pas en fournir une propre, migrez un arbre relu.

Nettoyer un site, en laisser trois

C'est le motif le plus fréquent des « on a déjà tout réinstallé ». La prod est neuve, le blog 2018 et le staging écrivent encore. Planifiez une vacation compte, pas une vacation URL. Si le budget est serré, fermez les morts d'abord (gain immédiat), puis la prod, puis les vivants secondaires.

Les secrets MySQL souvent identiques d'un wp-config à l'autre accélèrent le passage. Tournez les mots de passe base par site, grants séparés, après l'inventaire.

Quand changer d'hébergement

Si l'hébergeur ne peut pas isoler, si l'IP est sur plusieurs listes et qu'il refuse de bouger, si un voisin hors de votre compte (rare à prouver, parfois réel sur du très bas de gamme) continue de polluer. On migre après nettoyage du compte, pas à la place. Un nouvel abonné avec le même zip sale recommence l'histoire — migration infectée.

Un compte séparé par site, ou un VPS bien cloisonné, coûte plus cher qu'un mutualisé « 20 domaines ». Après deux réinfections latérales, l'écart de prix est le coût du troisième incident.

Après migration : l'ancien compte reste une rampe

DNS basculé, ancien `public_html` encore en ligne sur une IP : les bots le trouvent, les crons tournent, un webhook oublié répond. Fermez l'ancien compte ou videz-le. Révoquez FTP, clés, SMTP de l'ancien hôte.

Pour un inventaire de compte et une isolation, déclarez les hôtes. Un seul site déclaré alors que le panel en montre six, c'est le dossier qui revient.

• Liste des vhosts = liste des sites traités ou fermés.
• FTP / SSH du compte tournés.
• Grants MySQL séparés.
• Ancien hôte éteint après bascule.