WordPress Application Passwords - The Invisible Credentials You Need to Monitor

WordPress Application Passwords are one of those security features that are useful precisely because they are powerful. They allow external applications, scripts, integrations, and increasingly AI agents to authenticate with a WordPress website without knowing a user's actual account password.

That is a good thing. But there is an important security implication that many WordPress administrators overlook: - an Application Password authenticates as a real WordPress user and operates with that user's permissions.

If an Application Password belongs to an administrator, an application using that credential can potentially perform administrator-level operations exposed through the WordPress REST API, XML-RPC, or REST endpoints registered by plugins. This makes Application Passwords something every security-conscious WordPress administrator should actively inventory and monitor.

And recent events in the WordPress ecosystem demonstrate exactly why.

# What Is a WordPress Application Password?

Application Passwords were introduced in WordPress 5.6 as a built-in mechanism for programmatic authentication. Instead of giving an external application your normal WordPress password, you can generate a separate credential specifically for that application. For example, an Application Password could be used by a publishing application, a deployment script, a mobile application, an MCP server, an AI agent managing WordPress, etc.

WordPress explicitly describes Application Passwords as revocable, per-application credentials designed for programmatic access. They are tied to an individual WordPress user, stored hashed, and the plaintext password is displayed only when the credential is created. This is significantly safer than giving a third-party service your actual WordPress password. But safer authentication does not automatically mean limited authorization; and that distinction is extremely important.

# The Recent Rank Math Incident Is an Important Warning

In August 2026, Rank Math introduced a new AI-powered Support Agent in version 1.0.277. Rank Math's own changelog describes the release as adding a Support Agent and adding abilities allowing AI assistants to configure Rank Math settings. The plugin is installed on more than four million WordPress websites.

Security researchers subsequently reported that opening the Help & Support interface while using a connected Rank Math account could create a WordPress Application Password associated with the administrator account without presenting a separate consent step to the administrator. The credential was used to allow the remote AI support system to interact with the WordPress website.

On August 31, Rank Math temporarily paused the Support Agent, stating in its changelog that it was doing so while adding "further transparency to how it requests site access". The purpose here is not to single out Rank Math. The incident exposes a much broader problem - Do you actually know which Application Passwords exist on your WordPress website?

# Every Application Password Should Be Considered a Security Principal

Administrators often think about WordPress access in terms of users - I have three administrators, five editors, and twelve authors. But this is no longer enough.

Imagine that one administrator has six Application Passwords. From an access-governance perspective, you do not simply have one administrator identity to worry about. You potentially have the administrator's browser login plus six additional credentials capable of authenticating remotely as that administrator.

This is why Application Passwords should be treated similarly to API keys, service accounts, access tokens, and other machine credentials. They are part of your site's identity and access-management surface.

# The Administrator Application Password Is Particularly Dangerous

The principle of least privilege says that an identity should receive only the permissions required to perform its job. Creating an Application Password for your primary Administrator account is usually the opposite of least privilege.

Suppose an AI agent only needs to create draft posts, update post metadata and read categories. There is little reason for that AI agent to authenticate as an Administrator. Yet using an Administrator account is often the easiest integration path. That convenience dramatically increases the potential blast radius.

If the external system is compromised, the Application Password leaks, an AI agent behaves unexpectedly, or a prompt-injection attack causes an agent to issue unintended operations, the credential may provide significantly more authority than the agent actually requires.

# AI Agents Make This Much More Important

For years, Application Passwords were a relatively obscure WordPress feature. AI changes that and AI agents increasingly need the ability not merely to read WordPress data but to act. They may create content, update SEO settings, change metadata, upload media, configure plugins or perform administrative operations.

Application Passwords are an obvious authentication mechanism for these systems because they are already built into WordPress. As a result, we should expect significantly more Application Passwords to exist across WordPress installations over the next several years. That makes credential governance increasingly important.

# Recommended Security Practices

For security-sensitive WordPress environments, we recommend several basic rules.

• Avoid creating Application Passwords for Administrator accounts whenever possible. Create dedicated users for external systems and grant them only the capabilities necessary for their purpose.

• Use one credential per integration. Do not share the same Application Password between unrelated services. Separate credentials make revocation and auditing significantly easier.

• Review Application Passwords regularly. Every privileged user should be checked for unexpected, unused, or obsolete credentials.

• Revoke credentials you cannot explain. If nobody knows what an Application Password is for, keeping it active is difficult to justify.

• Monitor creation and usage. A newly generated Application Password for a privileged account should be considered a meaningful security event.

• Review the permissions behind the credential. The password itself does not determine the authorization boundary. The WordPress user does.

• Apply least privilege to AI agents. An AI content assistant usually should not authenticate as your website's primary administrator.

# Application Passwords Are Not the Problem

Application Passwords themselves are not insecure. They solve an important security problem by allowing applications to authenticate without receiving a user's primary password. They can also be individually revoked if an integration is compromised.

The problem is unmanaged access.

A perfectly secure credential attached to an excessively privileged identity is still excessive access. A credential or privilage you do not know exists cannot be properly governed. An AI agent authenticating as an Administrator is still effectively operating with an Administrator's authority, regardless of how securely its password was generated.

This is the broader lesson from the recent events surrounding AI integrations in WordPress.