Compte administrateur WordPress bloqué ou introuvable
Un second Super Admin, un email modifié ou une redirection sur `/wp-admin` suffisent à vous faire croire que « le compte a disparu ». On reprend la main via la base ou l’hébergeur, pas en réinstallant WordPress. wp-admin bloqué n’est pas une raison de tout jeter.
Un second Super Admin, un email modifié ou une redirection sur /wp-admin suffisent. On reprend la main via la base ou l'hébergeur, pas en réinstallant.
Ce que vous voyez : login, redirect, ou utilisateur vide
Trois tableaux. 1) Le formulaire accepte encore l’identifiant, puis « cet utilisateur n’existe pas » ou mot de passe refusé — email / pass changés, ou compte renommé. 2) `/wp-admin` redirige vers la home, vers un phishing, ou vers une 404 — règle `.htaccess`, plugin, ou `siteurl` en base. 3) Vous entrez, vous n’êtes plus administrateur — rôle rétrogradé, ou vous n’êtes plus le bon user.
« Plus d’admin WordPress » n’est donc pas un seul bug. Notez l’URL exacte après clic, le message, un compte de secours si vous en aviez un. Capture. Ne créez pas un deuxième WordPress dans un sous-dossier « pour avoir un admin ». Vous empilez un CMS sur un CMS compromis.
Si le front redirige aussi, ce n’est plus « juste l’admin ». Traitez comme site qui redirige en plus de la reprise de compte. Si seul l’admin casse après une maj, piste plugin — mais un attaquant aime se cacher dans cette excuse.
- Message d’erreur recopié mot pour mot.
- URL finale (barre d’adresse).
- Un autre compte de l’équipe, testé une fois, pas vingt.
Le second Super Admin et l’email changé
Dans `wp_users` (préfixe parfois autre que `wp_`) : un user créé à 3 h, `user_email` chez un webmail que vous ne connaissez pas. Dans `wp_usermeta`, `wp_capabilities` = `administrator`. Votre user existe encore, ou a été rétrogradé `subscriber`. C’est le scénario le plus net.
Votre email d’admin modifié : « mot de passe oublié » part chez eux. Vérifiez `user_email` et l’option `admin_email`. Remettez les vôtres, tournez le pass, invalidez les sessions. Mot de passe changé sans vous : même famille, autre angle.
Multisite : un Super Admin dans `wp_sitemeta` / `site_admins`. Un admin d’un seul site ne suffit pas. Regardez le réseau, pas seulement le blog 1.
Quand `/wp-admin` n’est plus votre admin
`.htaccess` : Rewrite vers un domaine tiers, ou Deny sur `wp-login.php`. Plugin de « hide login » dont le slug a changé (parfois l’attaquant, parfois vous l’avez oublié). `siteurl` / `home` en base pointant ailleurs. Un mu-plugin qui `die()` ou redirige si `is_admin()`.
Testez `/wp-login.php` et `/wp-admin/`. Si login marche en URL directe mais `/wp-admin` redirige : souvent cookie / `siteurl`. Si rien ne marche : htaccess ou prepend. Isoler `.htaccess` (renommer, poser le stub WP) est un test de cinq minutes, après copie.
Un clone de login (phishing hébergé sur votre domaine) peut usurper l’URL que vos marque-pages utilisent. Vérifiez le HTML. Phishing.
Reprendre via phpMyAdmin (sans casser les hash)
Panel → phpMyAdmin → table users. Pour un nouveau mot de passe : WordPress attend un hash PHPASS / bcrypt selon version. Le plus sûr : un outil « générer un hash WP » hors site, ou WP-CLI `user update`. Coller un MD5 brut ne marche plus sur les WP récents. Ne videz pas la table.
Pour remonter un rôle : dans `usermeta`, `wp_capabilities` = `a:1:{s:13:"administrator";b:1;}` et `wp_user_level` = 10. Adaptez le préfixe. Une faute de frappe ici = user cassé, pas admin.
Créez plutôt un nouvel admin propre, connectez-vous, retirez les fantômes depuis l’UI. Moins d’erreurs SQL. Ensuite secrets panel — l’ordre panel d’abord reste vrai : un attaquant avec le panel réécrit la base après vous.
WP-CLI et le file manager : les autres portes
SSH : `wp user list`, `wp user create`, `wp user update … --role=administrator`. Plus propre que SQL à la main. `wp option get siteurl`. `wp plugin deactivate` si un plugin bloque l’admin.
Sans SSH : file manager, déposer un `create-admin.php` unique, l’exécuter une fois, le supprimer tout de suite. C’est risqué (si vous le laissez, c’est une porte). Préférez phpMyAdmin. Si vous le faites : nom aléatoire, une requête, delete, vérifier qu’il n’est plus là.
Renommer `plugins` en `plugins.off` : si wp-admin revient, un plugin bloquait (sécu trop zélé, ou malware). Réactivez un par un. Copie avant.
Sessions, salts, et Application Passwords
Rentrer ne suffit pas. Régénérez AUTH_KEY etc. dans `wp-config.php` (générateur WordPress.org). Tout le monde est déconnecté, y compris les cookies de l’attaquant. Révoquez les Application Passwords.
« Se souvenir de moi » sur un PC d’agence : changez, déconnectez. Les sessions `wp_usermeta` `session_tokens` : on peut les vider pour un user.
2FA : activez après reprise, pas avant d’avoir un second facteur que vous tenez. Un 2FA posé par l’attaquant sur son user, vous le retirez avec ce user.
Après le retour : lister, révoquer, dater
Tous les users, toutes les dates. Médias uploadés la nuit. Extensions inconnues. Réglages `siteurl`. Cron. Vous avez l’admin : servez-vous-en pour l’inventaire, pas pour « republier la home et partir ». Défacement.
Cherchez comment ils ont créé l’admin : register ouvert, XML-RPC, faille, panel. Fermez ça. Sinon un troisième Super Admin naît jeudi.
Si wp-admin est à vous et le front encore sale : vous n’avez fini que la serrure du back-office. Le site, non.
Ce que la réinstallation ne règle pas
Un WP neuf dans `/wordpress/` laisse l’ancien tree et l’ancienne base. Vous avez un admin sur un site vide, les visiteurs voient encore l’infecté. Réinstaller : geste cœur, pas solution à un user SQL.
« Mot de passe oublié » sans contrôler `admin_email` : le lien part chez eux. Panel + base, pas le formulaire public, tant que l’email n’est pas le vôtre.
Prestataire disparu : récupérer le panel d’abord. Sans panel, pas de phpMyAdmin.