aBlocks <= 2.17.0 - Authenticated (Contributor+) Privilege Escalation to 'roleSlug' Block Attribute
Impact
The aBlocks WordPress plugin, versions up to 2.17.0, has a privilege escalation vulnerability. Authenticated attackers with Contributor-level access can escalate their role to non-administrator roles like Editor. The impact is bounded below administrator-tier roles.
Summarized by @cf/meta/llama-3.3-70b-instruct-fp8-fast. Verify details against the original sources.Affected packages
Affected products
Vendor version evidence. Product records are separate from automatic dependency matching.
kodezen · Wordfence
aBlocks – Gutenberg Blocks, User Dashboard Builder, Popup Builder, Form Builder & Animation Builder
1 range
kodezen · Wordfence
aBlocks – Gutenberg Blocks, User Dashboard Builder, Popup Builder, Form Builder & Animation Builder
Compare with this publisher’s ranges. This does not inspect your installation.
affected
0 → through 2.17.0
semver versions
Other versions: unaffected
Original source 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.
Inside the record
Evidence available
Describes the evidence in this view, not whether the product is safe.
Original records
CVE-2026-110018View the latest unmodified CVE JSON from the official source. It may be newer than this imported page.
cve.new JSON →Underlying weaknesses
The source’s classification of what caused the vulnerability.
Contributing organizations · 2
Assigning organization
Additional data publisher
What changed
Follow changesLarge field values are marked as truncated previews. Original source snapshots remain retained.