Live › vulnerability › CVE-2026-110018
Go to dashboardThe aBlocks WordPress plugin up to and including 2.17.0 exposes a REST registration endpoint whose handler trusts a roleSlug stored in post block attributes, without checking the form type at request time. A logged-in Contributor can save a crafted block, trigger the endpoint, and receive a session at a higher role, up to Editor.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-24 12:47 UTC. All times on this page are UTC.
Sites running the aBlocks plugin at version 2.17.0 or earlier where users with Contributor role or higher can create or edit posts. Exposure depends on the attacker already holding a Contributor-level account, so sites that only have administrators and subscribers are less exposed.
No product ranges from the sources yet.
wp plugin get ablocks --field=version (the package name is unknown from sources, so confirm the slug)/ablocks/v1/form-builder/registration REST route with curl -s https://example.com/wp-json/ablocks/v1/ and check whether it is listed2.17.0; the patched version number is unknown from sourcesEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-110018")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.