Dormant WordPress Users: Safe Cleanup and a Preventive Policy

Subscriber accounts dormant for years are an attack vector. Here is how to identify them, delete safely and define an ongoing policy.

A subscriber account registered three years ago, password never changed, mailbox no longer in use - that account is inactive but still exists. From a security angle it is an attack vector: its password may appear in another site's credential leak and through credential stuffing an attacker can log in to your site as a "legitimate" user.

Why this matters

Bots that scan WordPress sites en masse run automated logins against leaked password lists (rockyou.txt, COMB and others). If a subscriber on your system used password123 six years ago and that password is on the list, the bot logs in. A subscriber alone cannot do much, but: (1) certain privilege-escalation bugs let an authenticated subscriber elevate themselves through an insecure AJAX endpoint (known vulnerabilities and similar); (2) an authenticated session unlocks partial wp-admin, an authenticated REST API and ?author= enumeration; (3) suspicious behaviour from a subscriber account misleads incident response - it looks like "the user themselves" rather than an attack. Cleaning up dormant accounts shrinks the attack surface and reduces log noise.

How to detect

WordPress does not natively store last_login - you need a plugin. Options:

  • Install WP Last Login or Simple History which begin recording from the day they are activated.
  • Inspect user_registered in wp_users and any user_activity meta you have.
  • Via WP-CLI:
    wp user list --role=subscriber --field=ID,user_login,user_registered --orderby=user_registered

RankPlus identifies users with a registration date older than 365 days, no comments, no posts and no related post_meta.

How to fix

  1. Install the free Inactive User Deleter or WP Inactive User Cleanup.
  2. Set safe criteria: 365 days without login, subscriber role only, no posts, comments or WooCommerce orders.
  3. Run dry-run / preview first - you get a list of accounts about to be deleted. Review it manually.
  4. When deleting through Bulk actions > Delete, the Attribute all content to option appears. Pick your main admin user - this matters because comments, posts and ACF fields tied to user_id break if the user simply vanishes.
  5. WP-CLI alternative:
    wp user delete 123 --reassign=1
    This removes user 123 and reassigns their content to user 1.
  6. After cleanup close the door: Settings > General > Membership - uncheck "Anyone can register" if open registration is not required.

Common mistakes

  • Bulk-deleting without review: a real customer who has not visited in a year gets deleted - and would have come back with money.
  • Deleting an editor or author: they own posts. Without reassignment those posts break.
  • Ignoring WooCommerce: an old customer with prior orders is not "dormant" - they have purchase history. Filter by orders.
  • Skipping compliance checks: certain regulated sites must retain user records for a minimum period. In that case disable the account (Disable Users plugin) instead of deleting.

Verifying the fix

Run wp user list --role=subscriber --format=count and compare to the pre-cleanup count. RankPlus returns to green. Verify the site still works: log in as an existing subscriber, open a page, confirm a recent comment is still attributed correctly.

Tip: In addition to a one-time cleanup, schedule a weekly cron with WP-CLI to email a stale-user list - this turns cleanup into a habit instead of a project.