PAGUP Agent ControlWordPress access for AI assistants
Start free trial

WordPress Application Password Returns 401 Unauthorized

A 401 Unauthorized response normally means the request did not establish an acceptable authenticated identity. Check the username, Application Password value, Authorization header transport and whether Application Passwords are available before investigating WordPress capabilities.

Likely causes

  • The client sends the wrong WordPress username for the Application Password.
  • The Application Password was copied incorrectly, expired from the client’s configuration or was rotated.
  • The expected Application Password was never created, was revoked or belongs to another profile.
  • The hosting stack, reverse proxy, redirect or WAF removes the Authorization header before WordPress receives it.
  • A security plugin, must-use plugin or custom filter disables Application Passwords globally.
  • The client calls the wrong domain, base path, REST route or MCP endpoint.

Diagnostic sequence

  1. Capture the exact sanitized message, HTTP status and response body without including secrets.
  2. Record WordPress, plugin, client, connector and server versions before changing anything.
  3. Separate authentication failure from authorization refusal by comparing status, error code and response context.
  4. Verify through sanitized server evidence that the Authorization header reaches WordPress.
  5. Verify that the username sent by the client matches the owner of the Application Password.
  6. Use a minimal authenticated identity check to confirm which WordPress user the request represents.
  7. Check whether Application Passwords are globally available in the active WordPress environment.

Apply the smallest correction

  1. Configure the exact WordPress username and the current Application Password as separate values.
  2. Configure the trusted server or proxy path to pass the Authorization header to WordPress.
  3. Create one named Application Password for the dedicated identity and a single integration purpose.
  4. Remove or narrow the filter that disables Application Passwords only after confirming the intended security policy.
  5. Correct the client endpoint, transport, tool name or credential reference without broadening WordPress permissions.

Verify the result

  • The authenticated request resolves to the intended dedicated WordPress user.
  • The approved narrow read succeeds with a reproducible response.
  • Sanitized server evidence confirms that the Authorization header reaches WordPress.
  • After revocation, the same credential can no longer authenticate.

What not to do

  • Do not grant administrator access merely to make a connection test pass.
  • Do not place an Application Password, Authorization header, token or cookie in a prompt, ticket, log excerpt or screenshot.
  • Do not expose debug logs or diagnostic endpoints publicly.
  • Do not repeatedly regenerate credentials or retry the same failing request without understanding the lifecycle.
  • Do not confuse successful authentication with permission to perform every WordPress action.

Sources and verification

This page was checked against the following primary sources. Last source review: .