Unknown WordPress Application Passwords: How to Review Access

After a security incident, a WordPress user profile may show an Application Password with a name nobody recognizes. The first reaction is often to delete them all or change the main login password. Either choice can create problems: removing every token may interrupt backups, publishing, or business workflows, while changing the login password alone does not necessarily remove an active Application Password.

The short answer: inventory Application Passwords per user, match names and usage metadata to integration owners, then revoke credentials that are unauthorized or exposed. WordPress describes them as revocable per-application credentials for programmatic access; they are stored hashed, shown in full only when created, and can be revoked individually without changing the user’s primary password (official Application Passwords guide). Because a token uses the capabilities of its WordPress user, treat it as meaningful access—not merely as an application label.

This guide is for operators authorized to administer the site. Do not try to use a discovered token, ask someone to send its value in chat, or copy secrets into a public ticket. If you also find an unknown administrator, continue with our guide to a hacked WordPress site as part of the wider access response; this article focuses on application credentials, not on newly created admin accounts.

Understand the credential before changing it

An Application Password lets an application, script, or integration authenticate programmatically to WordPress, including the REST API and, in some configurations, XML-RPC. It is tied to one WordPress user, is not used for an interactive sign-in to /wp-admin/, and requests inherit that user’s capabilities. If the linked account is an administrator, do not assume the token is limited to the function described in its name.

WordPress stores a hash rather than a readable copy of the password. The complete value is shown when it is created; a later inventory may show the name, creation time, last use, or last IP depending on the version and management method. No recent last-used value does not prove that a token is malicious or safe. A legacy integration may run infrequently, server clocks can differ, requests may come through a proxy, and a clear name does not authenticate the client.

Also distinguish Application Passwords from the primary password, session cookies, plugin tokens, third-party service API keys, database credentials, and SSH keys. Revoking one token closes only that credential. If evidence points to compromise of the user or server, assess login rotation, sessions, other APIs, and hosting access separately.

Reduce risk and record a baseline

Before revocation, save a restricted inventory: WordPress user ID or login, application name, creation date, last-used time, last IP, integration owner, business purpose, and decision. Record the UUID only if the authorized operator needs it. Do not export a password value; the value cannot be retrieved from the hash. Mask email addresses, IP details, and other personal information if notes must be shared more widely.

If there is evidence of active abuse affecting visitors or data, containment may be more urgent than waiting for every owner to reply. Record the reason, time, credentials affected, and likely disruption before acting. If there is no abuse indicator and critical integrations depend on the credentials, arrange a short change window: identify the owners, prepare replacement secrets, test the integrations, and revoke old tokens after approval.

Review administrator accounts, login dates, notifications about user changes, and approved work tickets as well. An unusual token name is a finding to verify, not proof of who created it. If nobody recognizes the owner, look for REST API access logs, hosting logs, plugin audit events, deployment records, and vendor communication. Do not send a request with the found password just to see whether it still works; that can expose or extend access.

Inventory one user at a time

Start from the WordPress user profile using a verified administrator account. Open the relevant user’s profile, review the Application Passwords section, and record the name and metadata available. In a multisite installation, confirm that you are looking at the correct site and user; an integration may work for one site but not another.

An operator with SSH access can use WP-CLI and limit the returned columns. Review one account at a time:

wp user application-password list <user-id> --fields=uuid,name,created,last_used,last_ip

<user-id> is a placeholder; use the correct ID, login, or email under your access policy. The official wp user application-password list reference documents its fields and options. The output contains sensitive metadata; store it locally, do not commit it, and remove working copies when the investigation is done.

Match each application name against an integration inventory: CRM, booking system, mobile app, publishing tool, deployment pipeline, backup, or service desk. Contact the owner through a verified channel already on file, not an address or number that appears in a suspicious record. Ask which user created the connection, when it was enabled, where the secret is stored, and who approved it. Do not infer a client’s identity from names such as “mobile”, “backup”, or “API”; names are entered by users and do not authenticate the client.

Compare last_used and IP information with available logs. An IP may represent a proxy, NAT, CDN, or vendor gateway, so do not label one unfamiliar address as an attacker without context. Look for endpoint, time, user ID, status, request volume, and content changes. Avoid recording Authorization headers or bodies containing tokens. If logs are unavailable, document that evidence gap and ask the host or vendor to help.

Decide whether to revoke one token or contain more broadly

Use a tiered decision. Revoke one Application Password when its owner says the integration was never approved, the credential is no longer needed, it was exposed, or logs show unauthorized use. Coordinate a brief change window when the token has a legitimate owner, is actively used, and there is no compromise indicator—prepare a replacement, test it, then remove the old one. Escalate as a wider incident if the linked account was taken over, roles changed, REST requests created unauthorized content, or multiple credentials and server components are affected.

If a credential is confirmed to be abused, do not wait for a routine rotation cycle. Revoke it with the incident owner’s approval, document potential service impact, and contact the integration owner through a trusted recovery channel. If removal affects payment, orders, or a critical process, notify the business owner and prepare an approved manual fallback. Do not leave unauthorized access active simply because an integration might be disrupted; assess both risks.

To remove one token through WP-CLI, an authorized operator can use the UUID from the inventory:

wp user application-password delete <user-id> <uuid>

Use the target that has been confirmed; do not add --all as a shortcut. The official delete command reference explains that this option can remove every Application Password for a user. In the dashboard, use the revoke control next to the correct credential. Record the time, operator, reason, masked UUID, and result of a subsequent request.

Restore integrations without sharing a primary password

After a token is revoked or confirmed to need replacement, its integration owner should create a new Application Password for one application and one appropriate account. Where possible, use a dedicated account with the lowest role that can perform the required task, rather than sharing an administrator credential across tools. WordPress notes that the token follows the capabilities of its user; separate accounts can reduce the impact if one secret leaks.

Store the new value directly in an approved secret manager or vendor configuration through a controlled channel. Do not put it in ordinary email, tickets, screenshots, open spreadsheets, sample code, or Git. Test only the minimum request needed, inspect logs and service status, then ask the owner to confirm the business workflow. Verify that backups, synchronization, or publishing jobs work before removing the old secret from its approved storage.

If several connections need recovery, keep an inventory of integration, owner, WordPress user, required endpoint, replacement date, test result, and closure status. A new token is not automatically safe simply because it was created after the incident: review the operator’s device, browser, secret store, user capabilities, and systems that can read the credential.

Finish access and persistence checks

Revoking an Application Password is not the end of the investigation. Review unknown users, role changes, primary passwords, sessions/cookies, plugins that can create users, mu-plugins, scheduled jobs, deployment files, XML-RPC if enabled, custom REST routes, SSH/SFTP, hosting panel, DNS, CDN, and third-party applications. Compare timelines with authentication logs, REST requests, content creation, and configuration changes. If the token was used to create spam, restore content and close the mechanism; deleting a credential alone will not do that.

Use our guide to securing WordPress for a small business to build a baseline for roles, updates, backups, and administrator access. Make changes layer by layer in staging where possible. After deployment, review authentication logs, relevant endpoints, changed content, and whether any unapproved Application Passwords were created. If a token keeps appearing, find the user, plugin, or integration that creates it instead of repeatedly clearing the list.

If hosting, database, or site-owner accounts are affected, involve the host and technical team; changing application passwords cannot repair a server that is still controlled by an attacker. Document the limits of the investigation and anything not verified. For systems handling personal data or transactions, involve the appropriate business/privacy owners before sharing logs or announcing that the incident is complete.

Prevent recurrence

Name credentials with the application, environment, and owner in mind, without putting a secret in the name. Use one credential per integration, least-privilege accounts, a protected secret store, HTTPS, a current owner list, and periodic reviews. Revoke tokens that are no longer used once the owner confirms the business purpose; do not leave them active without a clear reason.

Define staff and vendor offboarding, keep an inventory of who can create users or Application Passwords, and retain change logs. Test that backups can be restored, limit dashboard access according to policy, and review WordPress components that add custom endpoints or authentication. Use MFA for human accounts where supported, but do not assume it automatically protects every application token already issued.

Frequently asked questions

Does changing an administrator password automatically revoke Application Passwords? Do not rely on that. Review and revoke Application Passwords separately from the user profile or WP-CLI; programmatic credentials and interactive login passwords are different access paths.

Can I remove every Application Password after an incident? Only when the incident owner approves the impact and services are ready to recover. If evidence points to one token, individual revocation is usually more controlled. Use the remove-all option only as a planned containment measure.

Do an application name and last IP prove who used the token? No. The name is entered by the person creating the credential, and an IP may belong to a proxy or gateway. Match it against the owner, time, endpoint, logs, and approved changes.

Should I send an Application Password to a technician for testing? No. Do not share the secret. An authorized operator can review metadata and logs without retrieving a password that has already been created; if needed, make a new token under the approved user and access policy.

If you find an Application Password that cannot be matched to an approved integration after an incident, request a WordPress security audit to review users, endpoints, logs, and related access before disconnecting business services in bulk.