Answer in brief
CVE-2026-123769 records a High severity (CVSS 8.8) vulnerability in SureDash <= 1.13.0 - Authenticated (Custom+) Privilege Escalation to /suredash/v1/save-settings REST Endpoint. The current sources do not mark it as known exploited. The current feed maps brainstormforce/SureDash – Community, Courses & Member Dashboard (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 8.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps brainstormforce/SureDash – Community, Courses & Member Dashboard (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| brainstormforce/SureDash – Community, Courses & Member Dashboardgeneric | >=0 <=1.13.0 | Not reported |
Published upstream
Nov 13, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Nov 13, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Nov 13, 2026
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.
Quoted source text, attributed separately from HOL analysis.