Mot de passe admin changé sans vous : ce que cela signifie

Ce que ça signifie (deux hypothèses, pas une)

Mot de passe admin changé sans vous : soit quelqu’un s’est authentifié avec un secret déjà valide (pass trop simple, pass réemployé, Application Password, session cookie, accès panel → édition `wp_users`), soit une faille a permis d’écrire en base sans passer par le formulaire. Les deux sont un incident. Le second cache souvent un PHP. Le premier peut être « seulement » un humain (ex-collègue) — encore faut-il le prouver, et tourner quand même tout le reste.

Ne commencez pas par le formulaire « mot de passe oublié » sur le site. Si `admin_email` n’est plus le vôtre, vous offrez le lien à l’autre. Panel et base, comme pour un wp-admin bloqué.

Un email WordPress « votre mot de passe a été changé » que vous n’avez pas demandé : gardez-le (en-têtes, heure). C’est une pièce. Ça date. Ça ne dit pas encore qui.

• Hypothèse humaine : secret ou session déjà valides.
• Hypothèse technique : écriture base / fichier hors formulaire.
• Dans les deux : panel d’abord, puis CMS.

Ce n’est pas « j’ai oublié » : les indices

Vous entrez le pass du gestionnaire, refusé. Un second admin existe. `admin_email` a bougé. Un appareil inconnu dans un log de sécu. Des articles publiés à 4 h. Le front a un symptôme (redirect, spam). Un seul de ces indices + le pass refusé : traitez comme compromission, pas comme amnésie.

L’amnésie vraie existe (mauvais coffre, mauvais environnement FileZilla). Elle n’explique pas un user `wpsupport`. Croisez. Comment savoir.

Si deux personnes de l’équipe « ont le même admin » : vous n’avez pas un incident clair, vous avez un secret partagé. Séparez les users, 2FA, puis voyez si ça se reproduit.

Panel d’hébergement avant wp-admin

Celui qui a le panel réécrit la table users quand il veut. Reprendre wp-admin sans tourner le panel, c’est lui redonner le pass dans dix minutes. Reset panel, 2FA, utilisateurs FTP, puis phpMyAdmin pour votre hash. L’ordre est le même que quels mots de passe.

Si le panel refuse aussi : takeover plus large, ou prestataire disparu, ou suspension. Support hébergeur, identité. Pas un nouveau WordPress.

Cloudflare / DNS chez un tiers : si quelqu’un change les A, « votre » site n’est plus votre serveur. Vérifiez la zone. Un pass WP changé + des DNS changés : priorisez le DNS.

Révoquer sessions, cookies, salts

Un pass nouveau ne tue pas un cookie déjà émis. Salts dans `wp-config`, ou « déconnexion partout ». Videz `session_tokens` du user. Révoquez Application Passwords et clés REST. Sinon vous rentrez et on vous ré-éjecte une heure plus tard.

Les PCs du bureau : malware local, gestionnaire de mots de passe partagé, session navigateur épinglée. Changez depuis un poste sain. Un keylogger rend le nouveau pass immédiatement inutile.

xmlrpc / REST : limitez après. Un pass changé avec xmlrpc ouvert et un user encore valide ailleurs, ce n’est pas fini.

Lister tous les users, pas seulement le vôtre

Export ou capture de `wp_users` + rôles. Fantômes, éditeurs inattendus, emails cyrilliques. Ne gardez pas « on ne sait plus qui c’est, on le laisse ». Après incident, inconnu = révoqué.

PrestaShop : employés. Un « mot de passe admin changé » boutique est souvent un profil employé, pas le client 1. Même méthode, autre table.

Notez qui a le droit de créer un admin (capabilities, plugins « user switcher »). Ces plugins sont des portes. Désactivez-les s’ils ne sont pas nécessaires.

Email de reset : qui le reçoit maintenant

`admin_email`, `user_email`, les alias, la boîte du domaine si le MX est sur le même compte (lisible via panel). Remettez vos adresses, testez un reset à vous, vérifiez que rien ne part ailleurs (règles de transfert, hook pirate `phpmailer`).

Un hook qui intercepte les mails d’admin : plus rare, réel. Si le reset n’arrive pas et que l’email est le bon, cherchez un mu-plugin mailer. En attendant, passez par SQL.

Activez la 2FA sur la boîte de récupération. C’est la clé de tous les « mot de passe oublié » suivants.

Ex-prestataire, stagiaire, PC du bureau

Révoquez sans attendre l’aveu. Un accès « de confiance » n’apparaît pas dans les logs comme `evil`. Il apparaît comme 9 h 04 depuis l’IP de l’agence. Parlez-en en interne, tournez, contractuellement à l’avenir : accès nominatifs, fin de mission = révocation. Voir ancien développeur.

Ne jouez pas au détective sur Twitter. Chronologie, logs, RH si besoin. Le site, lui, a besoin de secrets neufs ce soir.

Si c’est clairement humain et rien d’autre (pas de PHP, pas de `site:`) : vous avez quand même un incident d’accès. Durcissez. Ne concluez pas trop vite « donc pas de malware » sans avoir regardé les fichiers une fois.

La suite : entrée et surveillance

Comment ont-ils pu changer le pass ? Brute force sans limiteur, pass dans un dump public, XSS admin, plugin, panel. Fermez cette porte. Surveillez 7 jours : nouveau changement, nouveau user, fichiers.

Déclarez si contrat cyber. Pièce : email « password changed » + chronologie. Assurance.

Vous pouvez ouvrir un dossier si la base ou le panel vous résistent. Reprendre un admin n’est pas le nettoyage du tree.