Login temporaire expiré : l’accès REST restait admin

Le prestataire a rendu le lien. Le client a vérifié le tableau des sessions : plus d’accès temporaire actif. Deux jours plus tard, un export via l’API REST part encore avec les droits d’un administrateur. Dans ce scénario illustratif, fréquent en reprise WordPress, le plugin de login temporaire a bien fermé la porte web — pas forcément le jeton Application Password créé pendant la fenêtre d’accès. On croit avoir coupé. Une surface admin reste ouverte.

Le problème n’est pas « un login temporaire mal configuré » en soi. C’est l’écart entre deux mécanismes d’auth qui ne partagent pas le même cycle de vie : la session / le lien magique expire, alors qu’un Application Password (ou un autre secret longue durée créé pendant la session) peut survivre et continuer à authentifier REST ou XML-RPC. Tant qu’on traite « lien expiré » comme « accès admin retiré », on ferme l’écran de connexion et l’on laisse une clé API encore valide.

Symptôme : accès coupé à l’écran, pas côté API

Au moment où le ticket arrive, les signes se contredisent. L’interface d’administration refuse le lien temporaire. Le tableau de bord du plugin affiche l’entrée comme expirée ou révoquée. Pourtant un appel GET /wp-json/wp/v2/users/me (ou un équivalent authentifié) répond encore avec un rôle élevé, ou un outil d’intégration continue de pousser du contenu. Aucune alerte spectaculaire : juste une capacité admin qui n’aurait plus dû exister.

Cette classe d’écart n’est pas réservée à un seul plugin. Elle apparaît dès qu’un accès « court » coexiste avec des credentials « longs » créés dans la même fenêtre — Application Passwords WordPress, jetons d’intégration, comptes techniques créés « pour la reprise ». Le métier voit un accès coupé. La surface technique voit encore une authentification valide. Côté maintenance, c’est exactement le genre de dette qu’une reprise doit inventorier avant de déclarer la porte fermée.

Cause : deux cycles de vie d’authentification

Le mécanisme illustratif, documenté notamment autour de Temporary Login Without Password et d’écarts de révocation (classe fréquente, correctifs publiés — voir notamment les avis WPScan ; viser une version corrigée ≥ 1.9.9), suit une logique simple. Pendant la fenêtre temporaire, un administrateur (ou l’accès temporaire lui-même) peut créer un Application Password sur un compte à privilèges. Ce secret vit dans la table des mots de passe applicatifs de WordPress. Il n’est pas le cookie de session du lien magique.

Quand le login temporaire expire, le plugin révoque en général l’entrée de login temporaire. Il ne garantit pas, selon les versions et les chemins, la révocation automatique de tous les Application Passwords créés pendant cette fenêtre — ni des autres secrets dérivés. Résultat : l’écran « temporary login » est propre, l’API Basic Auth (utilisateur + application password) peut encore passer. XML-RPC, s’il reste activé, offre une autre porte sur le même type de credential.

Autres causes plausibles du même symptôme, à ne pas confondre :

• un vrai compte admin permanent créé « pour dépanner » et jamais désactivé ;
• un cookie / token d’un autre plugin d’accès distant encore valide ;
• une clé d’API tierce (commerce, SEO, backup) avec rôle élevé ;
• un utilisateur avec rôle éditeur élevé créé hors du plugin temporaire.

La cause principale du scénario « login temporaire » reste le cycle de vie désaligné : révocation de la session courte sans inventaire des secrets longs. Les autres hypothèses produisent le même symptôme métier (« on a encore un accès ») mais se départagent par des tests distincts.

Preuve : tests discriminants

Avant de réinstaller WordPress ou de changer tous les mots de passe « au hasard », on sépare les hypothèses sur un environnement contrôlé (staging cloné si possible).

Hypothèse A — Application Password survivant. Test : lister les Application Passwords des comptes à privilèges (écran utilisateur ou table dédiée) ; tenter un appel REST authentifié avec un jeton créé pendant la fenêtre temporaire, après expiration du login temporaire. Résultat attendu si l’hypothèse tient : 200 authentifié alors que le lien temporaire est mort. Conclusion : révoquer explicitement ces secrets ; ne pas se fier à l’expiration du plugin seul.

Hypothèse B — compte admin permanent oublié. Test : inventaire des utilisateurs administrator (et rôles custom équivalents) ; comparer à la liste nominative attendue. Résultat attendu si l’hypothèse tient : compte hors liste, créé à la date de la reprise. Conclusion : désactiver / supprimer le compte ; ce n’est pas un bug du plugin temporaire.

Hypothèse C — XML-RPC ou autre porte encore ouverte. Test : vérifier si XML-RPC répond encore aux méthodes authentifiées ; tester les mêmes credentials hors REST. Résultat attendu si l’hypothèse tient : authentification réussie sur une autre surface. Conclusion : fermer ou restreindre la porte, et révoquer les secrets — les deux, pas l’un sans l’autre.

Hypothèse D — plugin non à jour / correctif manquant. Test : comparer la version installée au correctif publié (pour Temporary Login Without Password, viser une version corrigée, typiquement ≥ 1.9.9 selon l’avis applicable — vérifier la fiche WPScan / changelog du jour). Résultat attendu si l’hypothèse tient : version vulnérable encore en production. Conclusion : mettre à jour, puis refaire l’inventaire des secrets — la mise à jour seule ne révoque pas toujours l’existant.

Ces quatre tests collent à des artefacts — liste de jetons, liste d’utilisateurs, réponse API, numéro de version — plutôt qu’à un débat d’intention (« on avait bien expiré le lien »).

login temporaire  → expiré / révoqué (UI plugin)
Application Pass. → encore présent ? → REST 200 ?
users admin       → hors liste nominative ?
XML-RPC           → auth encore possible ?
plugin version    → ≥ correctif publié (ex. ≥ 1.9.9)

Correction maintenant, prévention ensuite

La correction traite ce qui est déjà ouvert. On révoque tous les Application Passwords des comptes touchés pendant la fenêtre temporaire — pas seulement « le dernier créé ». On inventorie et on désactive les comptes admin hors liste. On force la rotation des secrets d’intégration encore valides. On met à jour le plugin vers une version corrigée. On vérifie ensuite par un appel REST négatif (401/403 attendu) que les jetons révoqués ne passent plus. On ne se contente pas du voyant vert « temporary login expired » dans l’admin.

La prévention se pose avant d’ouvrir le prochain accès prestataire. Règle écrite : tout accès temporaire s’accompagne d’un inventaire de clôture (sessions, Application Passwords, utilisateurs créés, clés d’API). Préférer un compte least-privilege dédié à la reprise, pas un admin générique. Désactiver XML-RPC si inutile. Mettre à jour le plugin avant usage, pas après incident. Documenter qui a créé quoi pendant la fenêtre — date, compte, secret — pour que la clôture soit une checklist, pas une impression.

Séparer les deux évite un piège classique : mettre à jour le plugin et croire que l’historique est propre. Un correctif empêche souvent de nouvelles fuites de cycle de vie ; il ne remplace pas la révocation des secrets déjà émis.

Limites et ce que ce texte n’est pas

Ce texte décrit une classe fréquente — accès court révoqué, secret long survivant — illustrée avec Temporary Login Without Password et le cycle de vie des Application Passwords, pas un audit nominatif d’un site client. Les numéros CVE / avis évoluent ; la fiche WPScan et le changelog du plugin font foi le jour J. D’autres plugins d’accès distant peuvent produire le même écart sous d’autres noms. Le bon réflexe reste hypothèse, test sur artefact, conclusion.

Quand une reprise se termine sur « le lien a expiré » sans inventaire des jetons REST, la porte web est fermée et la surface API peut rester admin. Ce n’est plus un détail de plugin : c’est une dette d’authentification.

Si vous héritez d’un WordPress après intervention prestataire et que la clôture d’accès n’a jamais été inventoriée, le cadre opérationnel — revue, correctifs, non-régression — est décrit sur la page maintenance.