Description

The BuddyForms plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 2.10.5 via a form-type confusion attack through the `bf_post_type` parameter. This is due to the public frontend submission handler `buddyforms_form_response_no_ajax()` authorizing logged-out submissions based solely on the target form's `public_submit` flag while independently trusting the attacker-supplied `$_POST['bf_post_type']` to determine the post type of the newly created object — a cross-check introduced in 2.10.2 applies only to existing posts (`post_id != 0`) and is completely bypassed for new-object creation — combined with the `save_post` listener `buddyforms_edit_form_save_meta_box_data()` lacking both a `current_user_can()` capability check and a form-builder nonce, causing it to unconditionally persist attacker-supplied `$_POST['buddyforms_options']` for any newly inserted `buddyforms` CPT post. This makes it possible for unauthenticated attackers to insert a rogue BuddyForms form configuration with an attacker-controlled `new_user_role` value into the live global form registry, then submit a registration through that form to create a new WordPress account with administrator-level privileges and achieve full site takeover. Exploitation requires the WordPress site to have "Anyone can register" enabled and at least one public BuddyForms form attached to a page, both of which are standard BuddyForms deployment configurations.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-11-06T12:17:16.020Z",
  "pubdate": "2026-11-06T12:17:16.020Z",
  "executiveSummary": "BuddyForms for WordPress versions up to and including 2.10.5 contain a critical privilege escalation vulnerability rooted in insecure form-type handling and insufficient authorization checks.\nThe vulnerability allows unauthenticated attackers to perform site-wide account creation with arbitrary roles, including administrator, leading to full system compromise.\nThe flaw manifests due to a combination of form-type confusion in the frontend submission handler and an unauthenticated save-meta-box operation.\nSuccessful exploitation requires that the target WordPress site has the 'Anyone can register' setting enabled and at least one public BuddyForms form accessible on the frontend.\nBecause the attacker can manipulate the `bf_post_type` and inject malicious `buddyforms_options` via the metadata persistence layer, they can override standard registration workflows.\nThis vulnerability is classified as critical, as it bypasses standard access control mechanisms and does not require pre-existing administrative or authenticated user sessions.\nThe primary risk implication is a total site takeover, where an attacker gains high-privileged access to the WordPress backend and server environment.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper validation of the `bf_post_type` parameter within the `buddyforms_form_response_no_ajax()` function. When processing frontend submissions, the plugin fails to enforce strict type checking for new object creation.\nWhile a cross-check mechanism was introduced in version 2.10.2, it is strictly scoped to existing posts where `post_id != 0`. When an attacker initiates a new object creation, this check is bypassed, allowing the attacker to inject arbitrary `bf_post_type` values into the submission handler.\nThe vulnerability is further exacerbated by the `buddyforms_edit_form_save_meta_box_data()` function, which acts as a `save_post` listener. This function executes without any `current_user_can()` capability checks or nonces to verify the intent of the caller.\nThis allows an unauthenticated attacker to supply a malicious `$_POST['buddyforms_options']` payload. Because the system lacks authorization controls, it unconditionally persists this data into the global form registry for any newly inserted `buddyforms` CPT post.\nThe attack flow proceeds as follows: First, the attacker identifies a page containing a public BuddyForms form. Second, the attacker submits a request to the submission handler while supplying a crafted `bf_post_type` and a payload within the `buddyforms_options` parameter that defines a `new_user_role` as 'administrator'.\nThird, because the registration logic trusts the configuration injected into the registry, the subsequent user registration process honors the attacker-defined role rather than the site's default user role.\nFourth, the attacker registers a new account through the compromised form. The `buddyforms_edit_form_save_meta_box_data` listener ensures that the configuration, which now points to the administrative role, is fully applied to the registration process.\nFinally, the attacker successfully creates an administrative account, gaining full access to the WordPress dashboard and the underlying server environment. The impact is catastrophic, as it allows arbitrary code execution or site-wide data manipulation via the newly obtained administrative session."
}