This vulnerability in Wishlist Member (CVE-2026-12949) is a state confusion flaw where the mergewith parameter — designed to handle a legitimate edge case where a user starts registration twice — can be weaponized with zero prior access or authentication. The critical failure is asymmetric trust: the code validates the registration cookie on GET requests but treats POST parameters (mergewith containing a WordPress user ID, wpm_id containing a membership level) as authoritative without verifying they're bound to any validated transaction. An attacker simply submits no registration cookie and supplies any user ID as mergewith; the system processes this as a legitimate merge completion rather than rejecting the request for lacking registration state.
Two compounding design choices make this catastrophic. First, the role-preservation behavior when wpm_id references a non-existent membership level falls through to preserving the target user's existing role rather than rejecting the transaction — a defensive coding decision that becomes a privilege escalation path when the merge context itself is invalid. Second, email and password change notifications are explicitly suppressed in this code path, which is the strongest indicator that someone recognized the operation as dangerous enough to silence the alerts rather than fix the underlying access control.
The blast radius is total: sequential WordPress user IDs mean any account can be targeted without enumeration, and the privilege escalation happens in the same request as the takeover. There's no authentication requirement, no preconditions, no foothold needed.
Defensive actions: Audit your Wishlist Member installations for versions prior to the patched release and treat any exposed instance as potentially compromised — check user tables for accounts with unexpected role changes, particularly to administrator-level roles. The fix requires not just validating the registration session but changing the data model so mergewith references a pending registration token bound to the active transaction rather than a direct user ID that reaches wp_update_user(). If you're maintaining plugins with similar registration-merge features, audit whether POST parameters referencing existing system entities require explicit authorization checks independent of the session context — the registration state alone cannot be the security boundary when an attacker can simply omit it.