This CVE documents a security plugin that actively inverts your site's authorization model, making it more dangerous than running no plugin at all. The plugin was marketed to block user enumeration — a legitimate concern — but its implementation collapses WordPress's multi-layered capability system (create_users, edit_users, delete_users, promote_user) into a single check: is_user_logged_in(). Any authenticated user, including a Subscriber with minimal privileges, can create new administrators, demote existing admins, or delete user accounts. The original vulnerability was a low-severity reconnaissance issue; the fix converts it into complete privilege escalation.

The scope failure compounds this. The developer applied the permission_callback overwrite globally across POST, PUT, PATCH, and DELETE methods, not just the GET methods used for enumeration. A Subscriber who couldn't enumerate users can now modify them. The plugin's default-enable configuration means sites running it are vulnerable the moment they install it.

If you're running this plugin: your immediate threat isn't external attackers — it's any registered user on your site. A Subscriber account, even a stale one, is now an Administrator-level credential. Remove the plugin entirely. The enumeration risk you installed it to mitigate is a known limitation of WordPress REST API that predates this plugin and can be addressed through proper server-level configuration or a more surgical fix.

If you're evaluating security plugins: treat any plugin that modifies authorization callbacks with extreme skepticism. The WordPress REST API's rest_endpoints filter makes method-aware scoping deliberately difficult — the secure approach requires 30+ lines of careful iteration, while the dangerous approach is a five-line global overwrite. Plugins that take the frictionless path are not rare. Verify that any hardening plugin preserves WordPress's capability model rather than replacing it with binary gates. The phrase "security hardener" in a plugin name should be a red flag, not a reassurance — it often masks fundamental changes to your authorization architecture that you'll never see in an admin dashboard.