Mots de passe d'application WordPress oubliés

Ce que c’est (et ce que ce n’est pas)

Depuis WordPress 5.6, un utilisateur peut engendrer un mot de passe d’application : une chaîne longue pour l’API REST (et certains flux), sans donner le mot de passe de connexion. Utile. Oublié. Invisible dans « changer mon mot de passe ».

Ce n’est pas un cookie de session (ceux-là meurent en changeant les sels AUTH). Ce n’est pas une clé WooCommerce (autre écran). Ce n’est pas le mot de passe FTP. Quatre tiroirs, quatre listes après incident.

L’attaquant qui a été admin a pu en créer un nommé « backup » ou « wordpress ». Vous changez le mot de passe, vous forcez la déconnexion, le jeton reste. Le lendemain, un POST authentifié réécrit une option. C’est le motif le plus propre des « on a tout changé, ça revient » sans nouveau fichier sur le disque.

Ils survivent au nouveau mot de passe

C’est le piège de cet article. Le protocole « je change l’admin » est incomplet. Profil utilisateur → Mots de passe d’application, pour chaque compte privilégié (et les comptes qui n’auraient pas dû l’être).

Changer les clés AUTH dans wp-config invalide les cookies, pas ces jetons. Rebuild Docker non plus (volumes). Restore d’une base d’hier : les jetons d’hier reviennent.

Un compte « Rédacteur » avec un mot de passe d’application et une faille de capability : plus rare, à lister quand même. L’audit est par utilisateur, pas seulement « les admins que je connais ».

Où les lister dans l’admin et en base

Interface : chaque profil. Les intitulés (Nom de l’application) sont choisis à la création : « Mon appli », « IFTTT », une date, rien. Tout ce que vous ne reconnaissez pas : révoquer.

Si l’admin est cassé, la meta utilisateur `_application_passwords` (sérialisée) tient la liste. Lecture après copie SQL. On ne « forge » rien ; on supprime la meta ou on passe par WP-CLI `user application-password` si vous l’avez, sur votre instance.

Multisite : chaque user, éventuellement par site. Un super-admin a pu en créer un qui parle à tout le réseau.

• Tous les administrateurs.
• Les comptes créés pendant la fenêtre d’intrusion.
• Les comptes d’agence / stagiaire encore là.

Révoquer sans casser le métier

Notez ce qui avait l’air légitime (app iPhone du gérant, Zapier de la newsletter). Prévenez-les : ils recréeront après. Révoquez d’abord l’inconnu et tout ce qui date de la fenêtre d’attaque.

Si vous ne savez pas : révoquez tout, le métier se manifeste (l’app ne publie plus, le zap échoue). Moins grave qu’une porte. Recréez au compte-gouttes, nouveaux secrets, comptes dédiés (un user « zapier » avec le moins de droits possible — souvent ça veut dire « pas admin »).

Documentez. Le prochain audit de 30 jours compare la liste.

IFTTT, Zapier, applis mobiles, CI

IFTTT 2022 : le scénario classique. Plus personne ne s’en sert, le jeton est éternel. Zapier / Make : un scénario « new post → Slack » avec un user admin. GitHub Action qui déploie et parle à l’API. L’app WordPress sur le téléphone d’un salarié parti. Demandez autour de vous « qui publie encore depuis le téléphone » avant de tout révoquer sans prévenir : cinq minutes d’appel évitent un lundi sans blog et un jeton clandestin recréé « en urgence » par la même personne, encore admin.

Révoquer fait échouer ces flux. C’est le signal. Recréez avec un user dédié, 2FA sur le compte humain, pas de partage du jeton dans un channel Slack.

Les clés REST WooCommerce sont le cousin boutique. Même jour, autre écran (WooCommerce → Réglages → Avancé → REST API).

Créer ensuite, jamais pendant le doute

Pendant le nettoyage, n’ajoutez pas de nouveaux mots de passe d’application « pour que l’agence suive ». Ils resteront. Attendez la fermeture, puis recréez volontairement.

2FA sur les comptes humains d’abord. Un jeton d’application n’a pas de 2FA à chaque appel : c’est le principe. D’où la révocation facile et les users dédiés.

xmlrpc fermé + jetons encore valides = REST encore ouverte pour qui a le jeton. Les deux se traitent.

Avec xmlrpc, REST et les clés Woo

Checklist accès après incident : panel, FTP/SSH, users CMS + sessions/sels, application passwords, clés Woo, webhooks, SMTP, Search Console, CDN. Un seul oubli suffit à une réécriture. Imprimez-la ou cochez-la dans le constat : les listes mentales sautent toujours la même ligne, celle-ci.

Le guide WordPress pose l’ordre fichiers / users. Cet article est la ligne « users » que tout le monde saute.

Premiers gestes : panel avant de jouer aux jetons. Un attaquant panel recrée un admin et un nouveau mot de passe d’application pendant que vous révoquez.

Contrôle à J+7

Rouvrir chaque profil privilégié. Une ligne nouvelle sans ticket = incident ou un collègue pressé. Les deux se parlent.

Logs REST (si vous en avez) : 401 en masse après révocation, c’est normal (vieux zaps). 200 authentifiés sur `users` ou `plugins` : pas normal.

Déclarer si l’admin est inaccessible et que la meta vous dépasse. On révoque, on ne « teste » pas les jetons contre votre site comme un attaquant.