Ablocks Gutenberg Blocks User Dashboard Builder Popup Builder Form Builder Animation Builder
Monthly
Privilege escalation in the aBlocks WordPress plugin (Gutenberg Blocks, User Dashboard Builder, Popup Builder, Form Builder & Animation Builder) through 2.17.0 lets an authenticated attacker with Contributor-level access or above raise their own WordPress role to Editor and receive a fully authenticated session at the elevated level. The flaw sits in the plugin's `/ablocks/v1/form-builder/registration` REST endpoint, which is registered with `permission_callback => __return_true` and whose `register()` handler reads `roleSlug` from attacker-controlled block attributes without confirming the block's `formType` is actually `registration`; the save-time sanitizer only enforces that constraint for registration blocks. Impact is bounded below administrator - `is_safe_registration_role()` rejects any role carrying `manage_options`, `edit_users`, `delete_users`, `create_users`, `promote_users`, or `edit_theme_options`, so Editor is the highest role practically reachable on a standard installation. No public exploit code or active exploitation is identified at time of analysis, and the CVSS vector (PR:L) confirms the attack requires authentication.
Privilege escalation in the aBlocks WordPress plugin (Gutenberg Blocks, User Dashboard Builder, Popup Builder, Form Builder & Animation Builder) through 2.17.0 lets an authenticated attacker with Contributor-level access or above raise their own WordPress role to Editor and receive a fully authenticated session at the elevated level. The flaw sits in the plugin's `/ablocks/v1/form-builder/registration` REST endpoint, which is registered with `permission_callback => __return_true` and whose `register()` handler reads `roleSlug` from attacker-controlled block attributes without confirming the block's `formType` is actually `registration`; the save-time sanitizer only enforces that constraint for registration blocks. Impact is bounded below administrator - `is_safe_registration_role()` rejects any role carrying `manage_options`, `edit_users`, `delete_users`, `create_users`, `promote_users`, or `edit_theme_options`, so Editor is the highest role practically reachable on a standard installation. No public exploit code or active exploitation is identified at time of analysis, and the CVSS vector (PR:L) confirms the attack requires authentication.