aBlocks <= 2.17.0 - Authenticated (Contributor+) Privilege Escalation to 'roleSlug' Block Attribute
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
The aBlocks WordPress plugin (all versions up to and including 2.17.0) contains a flaw that lets logged-in users with Contributor-level access or higher raise their own account to a more powerful role, such as Editor, and gain a fully authenticated session at that elevated level. This could allow an attacker to access and perform actions that are restricted to their original, lower-privileged role.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
The aBlocks – Gutenberg Blocks, User Dashboard Builder, Popup Builder, Form Builder & Animation Builder plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 2.17.0 via the `/ablocks/v1/form-builder/registration` REST endpoint. The vulnerability exists because the endpoint is registered with `permission_callback => __return_true` and the `register()` handler reads `roleSlug` directly from attacker-controlled block attributes in `post_content` without ever verifying that the block's `formType` is `registration` — a condition that `RegistrationFormSanitizer::verify()` imposes only at save-time, meaning a Contributor can preserve an arbitrary `roleSlug` by saving a block with `formType='login'` and then triggering the endpoint via a valid `wp_rest` nonce and post-ownership check. This makes it possible for authenticated attackers, with Contributor-level access and above, to escalate their WordPress role to Editor or any other non-administrator role and receive a fully authenticated session at the elevated privilege level via `WP_User::set_role()` and `wp_set_auth_cookie()`. Escalation is bounded below administrator-tier roles because `is_safe_registration_role()` rejects any role holding `manage_options`, `edit_users`, `delete_users`, `create_users`, `promote_users`, or `edit_theme_options`, meaning the highest practically reachable role on a standard WordPress installation is Editor.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- kodezen aBlocks – Gutenberg Blocks, User Dashboard Builder, Popup Builder, Form Builder & Animation Builder
through 2.17.0
References 7
plugins.trac.wordpress.org
- browser/ablocks/tags/2.16.0/includes/api/form-builder-controller.php#L353
- browser/ablocks/tags/2.16.0/includes/api/form-builder-controller.php#L70
- browser/ablocks/tags/2.16.0/includes/api/form-builder-controller.php#L345
- browser/ablocks/tags/2.16.0/includes/blocks/form-builder/block-attr-sanitizer/sanitizers/form-builder/registration-form-sanitizer.php#L28
- browser/ablocks/tags/2.16.0/includes/api/form-builder-controller.php#L685
- changeset?reponame=&old=3756864%40ablocks&new=3756864%40ablocks