Un staging WordPress oublié a servi de rampe

Où se cachent les copies oubliées

Sous-domaine `staging.`, `preprod.`, `dev.`, `test.`, `old.`, `backup.`. Dossier `/wordpress-old`, `/wp-old`, `/copie`, `/httpdocs.save`, un addon domain qui pointe vers un répertoire de 2019. Les installateurs d'hébergeur (Softaculous, « staging » WP Toolkit, plugin WP Staging) laissent des copies avec un préfixe de tables ou un second vhost. Personne n'y touche plus ; les bots, si.

Listez les vhosts, les sous-domaines DNS, les dossiers à la racine du compte. Un `phpinfo` ou un `readme.html` WordPress dans un sous-dossier date l'oubli. Search Console parfois « voit » un hôte que vous avez oublié : propriété domaine vs URL, voyez propriété Search Console.

Un site « en construction » avec un plugin coming soon n'est pas inoffensif. Il a wp-admin, des plugins, souvent le même mot de passe que la prod. Traitez-le comme une surface, pas comme une ébauche.

• DNS : tous les A / CNAME du domaine.
• Panel : tous les dossiers web du compte.
• Plugins de staging encore actifs en prod.

Ce que le clone partage avec la production

Trois architectures. (1) Fichiers séparés, base séparée : le clone est un second site. Il infecte la prod si l'isolation du compte est faible (PHP qui écrit chez le voisin) ou si vous y copiez un zip sale. (2) Fichiers séparés, même base : n'importe quel admin du staging écrit les options et les users de la prod. C'est le pire. (3) Plugin de staging qui copie les fichiers dans un sous-dossier mais laisse des secrets communs (wp-config recopié).

Ouvrez les deux `wp-config.php`. Même `DB_NAME` ? Alors nettoyer la prod et laisser le staging admin ouvert est absurde. Même `AUTH_KEY` ? Les cookies peuvent se recouvrir selon les cookies domain. Même identifiants SMTP ? Le spam part « depuis la prod » dans les journaux d'envoi.

Un clone avec `WP_DEBUG` à true et des backups zip téléchargeables dans `/wp-content/uploads` est une fuite de dumps. Cherchez les `*.sql`, `*.tar.gz` publics. Voir aussi fichiers d'archives publics.

Indexé, donc déjà dans Google

`site:staging.votre-domaine.fr` ou `site:votre-domaine.fr/backup` : si des pages répondent, Google a une copie. Spam SEO sur le staging, alerte Safe Browsing sur l'hôte, parfois confusion avec la prod (même marque, liens croisés). Coupez l'indexation (auth HTTP, `noindex`, désindexation Search Console) après avoir coupé l'infection, pas avant seulement : un `noindex` sur un kit de phishing ne suffit pas, il faut retirer le kit.

Un staging qui redirige vers la prod, ou l'inverse, mélange les signaux. Notez les règles. Ne videz pas `.htaccess` des deux d'un coup.

Même base, même malheur

Si les deux wp-config pointent vers la même base, il n'y a qu'un site, deux portes d'admin. Fermez l'admin staging (auth HTTP, IP allowlist, ou coupure du vhost) en même temps que vous tournez les users. Un rôle élevé créé depuis le staging apparaît en prod.

Préfixe de tables différent (`wp_` vs `wpstag_`) : bases logiques séparées, mais souvent le même user MySQL. Un script sur le staging peut lister les bases et écrire dans `wp_`. Restreignez les grants MySQL après incident.

Mots de passe et secrets recopiés

Le staging a été créé en clonant la prod : mêmes admins, même SMTP, mêmes clés Stripe « live » parfois. Les gens mettent un `test` sur Stripe en prod et oublient que le staging a encore la clé live dans une option. Révoquez les clés vues sur le clone comme si elles avaient fuité — elles ont fuité, le clone étant plus mal tenu.

Webhooks Stripe / PayPal qui pointent vers `staging.` : soit ils ne servent plus (commandes « marchent » encore via un autre endpoint), soit un attaquant les a retournés. Vérifiez les URLs chez le prestataire. Même réflexe que webhooks détournés.

Fermer, protéger, ou nettoyer

Si le staging ne sert plus : retirez le vhost, le DNS, le dossier (après archive hors compte). Un dossier « au cas où » sur le même FTP est une récidive. Si vous en avez besoin : auth HTTP, IP du bureau, `Discourage search engines`, mots de passe distincts de la prod, pas de clés live, pas d'envoi SMTP réel (Mailhog, From jetable).

Si le staging est déjà infecté et que la prod est propre : ne le « fusionnez » pas, ne le migrez pas vers la prod. Nettoyez-le ou détruisez-le. Copier un zip de staging vers la prod est le scénario migration qui ramène l'infection.

Une auth HTTP seule sur un PHP déjà webshell n'empêche pas un attaquant qui a le shell. Fermeture = fichiers inaccessibles ou dossier hors web, pas seulement un `.htpasswd` sur `/wp-admin`.

Les voisins de dossier sur le compte

Le staging n'est qu'un cas d'oubli. Un vieux Joomla, un `phpMyAdmin`, un site « du stagiaire » : même compte, même risque d'écriture latérale. L'isolation et l'inventaire du compte entier valent plus qu'un énième scan de la prod. Voir voisin de serveur.

Après : robots, DNS, et backups automatiques

Retirez les enregistrements DNS morts. Demandez à Search Console le retrait du préfixe si des URL staging sont indexées. Coupez les jobs de « sync staging → prod » des plugins et des crons agence : ils réécrasent une prod propre. Documentez une seule procédure de refresh, avec secrets distincts.

Si le dossier vous échappe (trop de copies, trop de vhosts), déclarez le compte plutôt que d'en oublier un. Le prix s'affiche avant qu'on touche au FTP.

• Tous les hôtes du domaine listés.
• Aucune copie avec clés live / même base orpheline ouverte.
• Staging utile : auth + secrets distincts, ou destruction.
• Jobs de sync lus et nommés.