aBlocks EUVD-2026-109265

Requires an authenticated WordPress account at Contributor level or above on a site running aBlocks ≤2.17.0, plus a valid wp_rest nonce and satisfaction of the endpoint's post-ownership check. The specific precondition is that the attacker saves an aBlocks form-builder block with formType set to 'login' (not 'registration'), which lets an arbitrary roleSlug survive because RegistrationFormSanitizer::verify() only enforces the roleSlug constraint at save-time for formType='registration'; the /ablocks/v1/form-builder/registration endpoint is reachable by default because it is registered with permission_callback => __return_true. Key LIMITING factors: an existing low-privilege account is mandatory (not anonymous), and the achievable role is bounded below administrator - is_safe_registration_role() rejects any role holding manage_options, edit_users, delete_users, create_users, promote_users, or edit_theme_options, so Editor is the highest practically reachable role on a standard install.

This is a genuine, well-corroborated privilege-escalation flaw but one whose real-world urgency is moderated by its prerequisites and bounded impact. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N, base 8.8) correctly reflects a network-reachable, low-complexity attack requiring low privileges and no user interaction - the PR:L is key and is consistent with the description, which requires an existing Contributor-level (or higher) authenticated account plus a valid wp_rest nonce and a post-ownership check. It is therefore NOT remote-unauthenticated. The vuln.today decision label is 'this_week' (not act_now/emergency), aligning with a serious-but-not-fire-drill posture. No EPSS score, no CISA KEV entry, and no public exploit reference are present in the supplied data, so there is no signal of active or mass exploitation; absence of these is not proof of safety but does argue against widespread automated attack at this time. A material mitigating factor stated in the description itself is that escalation is capped below administrator tier - is_safe_registration_role() rejects any role holding manage_options/edit_users/delete_users/create_users/promote_users/edit_theme_options, so the highest practically reachable role is Editor. Net: a real priority for sites that allow Contributor-or-above accounts (e.g. multi-author blogs, membership/guest-post sites), and a lower concern for single-admin sites with no untrusted lower-privilege users. The main data gap is the lack of EPSS/KEV and no confirmed fixed-version number in the supplied references.

An attacker who already holds a Contributor account saves an aBlocks form-builder block with formType='login' while embedding an arbitrary roleSlug (e.g. 'editor') in the block attributes, exploiting that the registration-only sanitizer check is bypassed for non-registration form types. They then call the /ablocks/v1/form-builder/registration REST endpoint with their valid wp_rest nonce; the handler reads roleSlug straight from the attacker-controlled post_content and invokes WP_User::set_role() plus wp_set_auth_cookie(), returning a fully authenticated Editor session. No public exploit identified at time of analysis, though the attack is low-complexity given the described code paths.