Audit WordPress Application Passwords and Keys in 10 Minutes

A connection key can keep working long after you’ve forgotten which dashboard holds it. On 17-18 October, TeamUpdraft, the company behind UpdraftPlus, was breached. Stolen UpdraftCentral connection keys were used to send commands to connected sites, including commands to create admin accounts and install malicious plugins. Meanwhile, a coming WooCommerce change means more shop owners may soon create WordPress application passwords for AI tools. I’d check both kinds of access now. Give it about 10 minutes.

What an application password actually does

Application passwords have been built into WordPress since version 5.6. They let an app, script or integration connect through the REST API or XML-RPC. They can’t be typed into the normal wp-login.php form. That’s also why your login 2FA prompt doesn’t apply to them: they never touch that form.

Each password belongs to a particular WordPress user and gets that user’s permissions. There’s no setting to make the password itself read-only. An administrator’s application password can do what that administrator can do. WordPress stores these passwords hashed and shows the actual password only once, when you create it. You can’t retrieve or edit it later; you revoke it and make a new one.

The awkward bit? There’s no site-wide list. You have to look at each user’s profile. Access given for a project tends to stay there after the project ends, especially if nobody has been assigned to clean it up. I wouldn’t assume an old integration was removed just because nobody talks about it anymore.

The 10 minute checklist

1. Scan your users. Open Users > All Users. Look for former staff, agencies and freelancers. Remove accounts that no longer need access, or demote them if they still need a smaller role. I’d start with administrators, then check other users who may have connected tools.
2. Open each relevant profile. Go to Users > Profile for your own account, or use Users > All Users and select Edit for someone else. Scroll to Application Passwords. Each row shows Name, Created, Last Used and Last IP. There’s a Revoke button and an option to revoke all application passwords. Last Used updates at most once every 24 hours, so treat it as an approximate day, not a precise timestamp.
3. Revoke what you can’t account for. Check the tool name against the apps you still use. Ask whoever set up an integration before removing a password that may run it. If you’re sure it’s unused, revoke it. Changing the user’s ordinary password won’t remove their application passwords, so a password reset isn’t a substitute for this check.
4. Use WP-CLI if you manage many accounts. wp user application-password list <user> shows a user’s entries. wp user application-password delete <user> --all removes all of them for that user. Don’t run the second command as a shortcut unless you’re ready for their integrations to stop.
5. Check UpdraftCentral keys. Open Settings > UpdraftPlus Backups > Advanced Tools > UpdraftCentral and delete connections you don’t use. UpdraftPlus 1.26.13 (free) and 2.26.13 (Premium) revoke the old keys involved in the breach. Our UpdraftCentral key write-up has the background.
6. Look for other remote dashboards. Check ManageWP’s Worker plugin, MainWP’s Child plugin, Jetpack, and any backup or remote management connection you installed. If you’re done with its dashboard, remove or disconnect the site there first, then deactivate and delete the plugin on your site. If you don’t recognise the dashboard or account, remove that connection.
7. Review shop keys. In WooCommerce > Settings > Advanced > REST API, check each key’s description, user, permissions and Last access. Revoke keys you can’t explain or that haven’t been used for a long time. A key acts as the WordPress user it was created for; deleting that user also stops the key working.
8. Check access outside WordPress. An old agency login may be gone from Users while hosting, SFTP or another dashboard still grants access. Check those separately, along with the person’s application passwords and WooCommerce keys. Our guide to giving a developer access without losing control is useful before the next project starts.
9. Make a plan for connections you keep. Give each tool its own application password and, where possible, its own user with the lowest role that works. Put a quarterly reminder on your calendar to review them. Revoke and recreate passwords when someone leaves or you drop a tool. Otherwise, a useful connection can sit there untill everyone forgets who set it up.

---

AI connections need a limited user too

WooCommerce announced on 21 October that, coming in version 11.3, its /wp-json/woocommerce/mcp endpoint and REST API key login for MCP clients will be removed. MCP clients will need the WordPress MCP Adapter plugin and a WordPress application password instead. Version 11.3 isn’t out at the time I’m writing this. You don’t need to change a working connection today just because of that announcement.

When you do set one up, don’t hand an AI tool your main Administrator account by default. I’d try a dedicated Editor or Shop manager account first and see what the tool actually needs. Name the application password with the tool and month, so future you can tell it apart from the others. One password per tool means you can revoke a single connection without cutting off everything else. The password itself has no permission limits; the user’s role is what sets the boundary.

If you don’t use application passwords

You can turn the feature off with add_filter( 'wp_is_application_passwords_available', '__return_false' ); in a small plugin or mu-plugin. I wouldn’t put that in a theme’s functions.php if you might change themes. There’s also a per-user filter, wp_is_application_passwords_available_for_user, if you need finer control.

Turning the feature off hides it from profiles and stops existing application passwords from authenticating. Check Last Used and confirm which apps depend on it first. Our free Bearmor Security hardening options include a Disable Application Passwords switch under Hardening > Access hardening. It only turns the feature off. The audit is still a manual walk-through, and I’d do that before flipping any switch.

If a key looks wrong

An unfamiliar credential used recently deserves more attention than one with no recorded use. Don’t assume it’s harmless because the regular account password was reset. I would work through these checks:

• Revoke the application password or connection key you can’t explain.
• Check Users for unknown administrators and Plugins for plugins you didn’t approve.
• If you suspect someone got in, get help with hacked site cleanup rather than just deleting the odd-looking item and calling it done.

For today, open your own profile and scroll to Application Passwords. Read the names and Last Used dates. If you can’t say what a password connects to, that’s your next question to answer.