WordPress et PrestaShop sur le même compte : l'un a infecté l'autre
Très fréquent : le blog vitrine abandonné infecte la boutique, ou l'inverse. On inspecte les deux, on isole, on ne « sauve » que le Presta. Un plugin WordPress oublié est une rampe vers tout le panel.
Très fréquent. On inspecte les deux, on isole, on ne « sauve » que la boutique. Le blog vitrine abandonné est souvent la rampe.
Ce que « le même compte » veut dire
Un panel o2switch, OVH, Plesk : deux dossiers, parfois deux domaines, souvent le même utilisateur système. Le PHP de l'un peut lire la config de l'autre si les permissions sont lâches. Un cron, un `.env`, un `wp-config` : le voisin n'est pas un étranger. C'est le même appartement, deux pièces.
Les plugins de sécurité WordPress ne voient pas `/prestashop`. Les modules Presta ne voient pas `/blog`. Vous avez deux demi-constats. L'attaquant a le compte.
Voisin de serveur décrit l'isolation entre clients de l'hébergeur. Ici, c'est plus proche : deux de vos sites, un titulaire. L'isolation, c'est vous qui la posez — ou pas.
Le blog vitrine, rampe classique
WordPress 4.x, cinq extensions mortes, plus mis à jour depuis la refonte boutique de 2019. Personne n'y va. Les bots, si. Une faille Contact Form, un thème nulled, et le PHP écrit à côté, dans le dossier Presta, ou pose un utilisateur FTP via le panel si les identifiants sont les mêmes.
L'inverse existe : boutique 1.6 percée, le blog « clean » se fait réécrire `index.php` le lendemain. Dans les deux sens, « on a déjà tout réinstallé » sur un seul CMS garantit le retour.
Un addon domain, un vieux `.com` stationné sur le même panel, c'est une troisième pièce. Listez tous les domaines du compte. Addon / parked.
On ne sauve pas qu'une vitrine
Le réflexe « on s'occupe de la boutique, le blog on le fermera » laisse la rampe chaude. Fermer le vhost du blog, oui, si vous n'en avez plus besoin — après copie, et en tuant les URL (410) si elles étaient indexées. Le laisser en ligne « éteint » mais encore exécutable, non.
Migrer uniquement Presta vers un serveur neuf en laissant WordPress sale derrière : les mails et l'IP du nouveau peuvent rester propres un temps ; le vieux domaine blog continue de pourrir la marque, et un mot de passe de panel commun rouvre tout.
Les sauvegardes cPanel : une archive « complète » contient les deux infections. Restaurer « le compte » ramène les deux. Restaurer un seul dossier, c'est possible ; encore faut-il que l'autre ne réécrive pas.
Isoler : utilisateurs FTP, chemins, PHP
Un utilisateur SFTP par dossier, pas un login qui voit tout le home. Permissions sur les fichiers de config. open_basedir ou l'équivalent chez l'hébergeur si disponible. Ce n'est pas du luxe : c'est ce qui empêche le PHP du blog de lire `app/config` de Presta.
Mots de passe distincts, évidemment. Panel ≠ CMS — ici, deux CMS, donc encore plus de tiroirs.
PHP dans les uploads, des deux côtés. Interdire l'exécution dans les médias est le correctif le moins cher, deux fois.
- FTP/SFTP limité au DocumentRoot de chaque site.
- Secrets distincts : panel, WP, Presta, bases.
- Pas de `777` partagé sur le home.
Google, mails, et la réputation d'IP
Un blog qui envoie du spam ou héberge du phishing fait tomber l'IP. La boutique, « propre », voit ses devis en indésirables. Nettoyer Presta sans le blog ne suffit alors pas. Emails en spam, réputation IP.
Safe Browsing peut taguer le domaine du blog, ou l'IP, ou les deux. Les clients de la boutique tapent parfois encore l'ancien nom. Blacklist.
Search Console : deux propriétés, ou une propriété domaine si c'est le même registraire / le même suffixe. Regardez les deux `site:`.
Nettoyer les deux, dans quel ordre
Si du phishing est en 200, on tue cette URL d'abord, quel que soit le CMS. Ensuite : copie du compte entier, rotation du panel, puis le CMS qui encaisse (tunnel), puis le vitrine, puis les satellites (old, staging).
Ne commencez pas par « réinstaller WordPress pour vous faire la main ». Vous brûlez des heures et vous touchez aux journaux. Si vous déléguez, un seul dossier, un seul constat, les deux chemins. Devis : le périmètre est le compte, pas « le site de la carte de visite ».
Les premiers gestes s'appliquent une fois au panel, pas deux fois en oubliant le voisin.
Après : séparer ou assumer
Idéal : boutique sur un compte isolé, vitrine ailleurs ou statique, secrets étanches. Ça se planifie après clôture, ce n'est pas une migration sale du dimanche. Changer d'hébergeur encore infecté.
Assumer le même compte : isolation FTP, plus de site abandonné exécutable, surveillance des deux racines. Écrivez-le. Un troisième WordPress « test » dans six mois recrée la rampe.
Headless + Presta + WP : trois origines, un panel. La carte d'abord. WP headless.
Décider sans migrer dans la panique
Ce soir, vous ne « sauvez » pas la boutique en l'emportant sur un VPS avec le blog encore chaud derrière. Vous copiez, vous tournez le panel, vous faites inspecter les deux dossiers. La migration, si elle vient, part d'un compte déjà fermé.
Éteindre le blog sans 410 laisse `site:blog.marque.fr` pourrir. Tuez ou redirigez depuis un état propre.
Créer un espace : indiquez les deux CMS et les domaines du panel. C'est la phrase qui évite un devis pour moitié de compte.