CVE-2026-13171

This vulnerability is a waiting-list registration handler that creates WordPress user accounts and injects plugin-specific order records without any authentication or capability check. The critical detail that the CVSS score underweights: this isn't just unauthenticated user creation—it\'s unauthenticated user creation plus injection of data into the plugin\'s internal state. Other plugin components likely query these order records without re-verifying authentication, because the existence of the record itself becomes the trust signal. That's the cascade path: attacker creates a WP account, the plugin writes a trusted order record, and downstream plugin logic treats that record as validated context for privilege escalation within the plugin flow. If you're defending against this: check whether any plugin handlers registered to public-facing hooks (`add_action` or `add_shortcode` callbacks that process user input) create user accounts, write to custom tables, or modify plugin-specific data without verifying `current_user_can()` or validating a nonce first. The vulnerable pattern here was a convenience endpoint—waiting-list signup—added during feature development where the developer's mental model categorized it as "utility function" rather than "security surface." That categorization failure is the real vulnerability class, and it recurs because the development workflow likely lacks explicit coverage for unauthenticated request paths. The question to ask your team: does your plugin have test coverage that explicitly exercises every public-facing handler as an unauthenticated request? If the test suite assumes the happy path of logged-in users, the next feature will ship the same gap under a different label.

Reviewed through automated stages and approved by a human before publication.