CVE-2026-123769: SureDash <= 1.13.0 - Authenticated (Custom+) Privilege Escalation to /suredash/v1/save-settings REST Endpoint
The SureDash – Community, Courses & Member Dashboard plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 1.13.0 This is due to the savesettings() REST handler at /suredash/v1/save-settings being gated only by adminpermissioncallback(), which authorizes any holder of the custom manageportaldashboard capability (Portal Manager role) without requiring promoteusers, editusers, or manageoptions, combined with sanitizesettingsdata() iterating all attacker-supplied keys with no allow-list, allowing arbitrary keys such as defaultrole to pass through sanitizetextfield() unchanged and be persisted into the portalsettings option via updateoption() with no role-validity check. This makes it possible for authenticated attackers with Portal Manager-level access and above to poison the defaultrole setting to administrator, after which any subsequent new-user registration through the publicly accessible block-register endpoint reads the corrupted setting and passes it directly to wpinsertuser(), producing a full WordPress Administrator account under the attacker's control. The exploit requires two steps: a POST to the authenticated save-settings endpoint to overwrite defaultrole, followed by triggering a new registration through the unauthenticated block-register endpoint to receive the escalated account. Successful exploitation causes the attacker's own account to receive the complete administrator role.
Affected Software
Event History
Frequently Asked Questions
Which users can exploit this issue?
An authenticated user with the custom manage_portal_dashboard capability can exploit it. This includes the Portal Manager role and higher-privileged users.
What must an attacker do to obtain an Administrator account?
The attacker must first set the portal_settings default_role value to administrator through the save-settings REST endpoint. They must then register a new user through the publicly accessible block-register endpoint, which uses that poisoned default role when creating the account.
Is public registration relevant to exploitation?
Yes. The final privilege-escalation step relies on a subsequent new-user registration through the publicly accessible block-register endpoint. That registration creates the new account using the compromised default_role setting.
How can administrators check for signs of exploitation?
Review the portal_settings option for a default_role value of administrator and investigate whether unexpected Administrator accounts were created. In particular, look for accounts created after a Portal Manager or other holder of manage_portal_dashboard could have changed the setting.