CVE-2026-110018: aBlocks <= 2.17.0 - Authenticated (Contributor+) Privilege Escalation to 'roleSlug' Block Attribute
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 permissioncallback => returntrue and the register() handler reads roleSlug directly from attacker-controlled block attributes in postcontent 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 wprest 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 WPUser::setrole() and wpsetauthcookie(). Escalation is bounded below administrator-tier roles because issaferegistrationrole() rejects any role holding manageoptions, editusers, deleteusers, createusers, promoteusers, or editthemeoptions, meaning the highest practically reachable role on a standard WordPress installation is Editor.
Affected Software
Event History
Frequently Asked Questions
Which users can exploit this issue?
An authenticated WordPress user with Contributor-level access or higher can exploit it. The attacker must be able to use a valid wp_rest nonce and satisfy the post-ownership check.
What level of access can an attacker gain?
An attacker can change their role to Editor or another non-administrator role and receive an authenticated session at that elevated level. The described restriction prevents escalation to administrator-tier roles.
Which installations are affected?
All aBlocks versions through 2.17.0, including 2.17.0, are affected. The vulnerable functionality is the /ablocks/v1/form-builder/registration REST endpoint.
What can be done while remediation is pending?
Limit Contributor-or-higher access to trusted users, since those accounts meet the stated privilege prerequisite for exploitation. Review ownership and access to posts containing aBlocks content, because the exploit also requires passing a post-ownership check.