Ce que fait cet outil
Se connecter à WordPress demande un nom d'utilisateur et un mot de passe, mais la page de connexion ne révèle jamais directement quels noms d'utilisateur existent. Ce vérificateur teste deux mécanismes distincts, tous deux non conçus à l'origine comme des failles de sécurité, qui peuvent malgré tout révéler cette information : les archives d'auteur et l'API REST.
La redirection /?author=N
Chaque utilisateur WordPress possède une page d'archive publique listant ses articles, accessible via /?author=N où N est son identifiant numérique interne. WordPress redirige automatiquement cette URL vers l'adresse définitive de l'archive, qui contient le nom d'utilisateur — par exemple /author/admin/. Cette fonctionnalité existe pour un usage éditorial légitime (permettre aux lecteurs de retrouver les articles d'un auteur), mais elle fonctionne aussi comme un outil de découverte de noms d'utilisateur pour quiconque essaie systématiquement plusieurs identifiants.
L'API REST : plus rapide, potentiellement plus complète
L'endpoint /wp-json/wp/v2/users, introduit avec l'API REST de WordPress, peut renvoyer la liste des utilisateurs publics en une seule requête — nom d'utilisateur et souvent nom affiché complet, sans avoir à deviner des identifiants un par un comme avec la méthode par archive. C'est la technique la plus efficace des deux quand elle est disponible, et elle mérite d'être vérifiée indépendamment : un site peut avoir corrigé l'une des deux fuites sans avoir pensé à l'autre.
Pourquoi le nom d'utilisateur seul ne suffit pas à un attaquant
Connaître un nom d'utilisateur valide ne donne pas accès au compte — il faut encore le mot de passe correspondant, et WordPress limite normalement les tentatives de connexion répétées. Mais cette fuite retire la première moitié du problème pour un attaquant : au lieu de deviner à la fois le nom d'utilisateur et le mot de passe, il se concentre uniquement sur le second, ce qui réduit considérablement l'effort nécessaire pour une attaque par force brute ou par dictionnaire.
Une vulnérabilité ancienne, toujours largement présente
Ces deux techniques sont documentées depuis des années et pourtant restent efficaces sur une grande partie des installations WordPress par défaut, précisément parce qu'elles ne sont pas des bugs à proprement parler — ce sont des fonctionnalités qui ont un effet de bord non anticipé lors de leur conception initiale. Un correctif ciblé (bloquer la redirection ?author=N, restreindre l'endpoint REST users) suffit généralement à fermer les deux fuites sans affecter le reste du site.