CVE-2026-123769brainstormforce SureDash improper privilege management

What it is

The software lets a user or process gain privileges it should not have.

How it is reached

An attacker can exploit it over the network, with an ordinary user account, and nobody has to click anything.

What an attacker gains

A successful attack can read the data it protects, change data or behaviour and take it offline. In practice, this kind of flaw lets an attacker reach data or actions their role should not allow.

Is it being exploited?

There is no public report of exploitation yet. EPSS estimates a 0.58% chance of exploitation activity in the next 30 days, higher than 48% of scored CVEs.

What to do

1. No fixed version is listed yet. Find every place brainstormforce SureDash runs, watch the references for a fix, and plan a replacement if it is no longer supported.
2. While there is no fix, review who holds accounts that can reach it.

Description from NVD

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 `save_settings()` REST handler at `/suredash/v1/save-settings` being gated only by `admin_permission_callback()`, which authorizes any holder of the custom `manage_portal_dashboard` capability (Portal Manager role) without requiring `promote_users`, `edit_users`, or `manage_options`, combined with `sanitize_settings_data()` iterating all attacker-supplied keys with no allow-list, allowing arbitrary keys such as `default_role` to pass through `sanitize_text_field()` unchanged and be persisted into the `portal_settings` option via `update_option()` with no role-validity check. This makes it possible for authenticated attackers with Portal Manager-level access and above to poison the `default_role` 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 `wp_insert_user()`, 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 `default_role`, 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.