This CVE captures a registration bypass in a WordPress plugin where user accounts can be created even when the administrator has disabled registration site-wide in WordPress settings. The plugin implements its own registration form and handler, calling wp_insert_user() or wp_create_user() directly without checking the users_can_register option first. This is the vulnerability in its entirety — a missing conditional, typically fixable with a single check at the top of the registration handler: if (!get_option('users_can_register')) return; or returning a WP_Error.
What makes this worth your attention isn't the code-level simplicity — it's the blast radius. When you disable registration in WordPress settings, you are making a security decision that downstream systems then trust. Plugins that gate content, access tiers, or WooCommerce customer flows all operate under the assumption that users_can_register = false means no new accounts can be created. This plugin breaks that assumption silently. An administrator who disabled registration and then opened their site to verified customers has no interface indicating that accounts are still being created through this alternative path.
The fix for this specific instance is trivial. The pattern, however, is not an anomaly — it's the third or fourth registration bypass of this exact type in WordPress plugin history. The structural issue is that WordPress core's registration hooks (register_post, registration_redirect) assume you're using core's form. When a plugin builds a custom endpoint, there's no obvious integration point that says 'honor the site-wide setting or fail visibly.' The utility functions wp_create_user() and wp_insert_user() are precisely that — utilities. They perform user creation; they don't enforce policy. The security boundary lives at the integration layer, and a self-contained plugin bypasses that layer entirely.
Your action items: First, verify whether any active plugins on your site implement custom registration flows — membership plugins, directory plugins, and user submission plugins are the usual suspects. Second, check your user audit logs for accounts created around dates you believe registration was disabled. Third, if you maintain a plugin with registration functionality, audit the handler to confirm it checks get_option('users_can_register') before proceeding — one line of code that should be non-negotiable. Fourth, consider that disabling 'Anyone can register' in WordPress settings is not a hard security boundary for any plugin that implements its own user creation; it's a signal, and signals can be ignored.