The aBlocks – Gutenberg Blocks, User Dashboard Builder, Popup Builder, Form Builder & Animation…

Why it is Yellow

• CVSS 8.8 high

References

• https://plugins.trac.wordpress.org/browser/ablocks/tags/2.16.0/includes/api/form-builder-controller.php#L345
• https://plugins.trac.wordpress.org/browser/ablocks/tags/2.16.0/includes/api/form-builder-controller.php#L353
• https://plugins.trac.wordpress.org/browser/ablocks/tags/2.16.0/includes/api/form-builder-controller.php#L685
• https://plugins.trac.wordpress.org/browser/ablocks/tags/2.16.0/includes/api/form-builder-controller.php#L70
• https://plugins.trac.wordpress.org/browser/ablocks/tags/2.16.0/includes/blocks/form-builder/block-attr-sanitizer/sanitizers/form-builder/registration-form-sanitizer.php#L28
• https://plugins.trac.wordpress.org/changeset?reponame=&old=3756864%40ablocks&new=3756864%40ablocks
• https://www.wordfence.com/threat-intel/vulnerabilities/id/6fe7efb5-540b-4d85-852f-ad572da7ecdd?source=cve

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.