Summary
The Super Forms – Drag & Drop Form Builder plugin for WordPress contains a privilege escalation flaw in its Register & Login add-on. An authenticated user with Subscriber-level access or higher may abuse an insufficiently protected account-update flow to change credentials belonging to another user, potentially including an administrator.
Affected context
The vulnerability occurs in WordPress installations using the Super Forms Register & Login add-on and its account-update workflow. Risk increases when the form-saving AJAX action is accessible without an appropriate capability check and the update flow accepts a user identifier without verifying that the requester owns the target account or is authorized to manage it.
Exploit preconditions
- Attack surface: WordPress AJAX actions exposed by the Super Forms plugin
- Required access: An authenticated account with Subscriber-level access or higher
- Trigger point: Submission of a crafted form through the Register & Login account-update flow
- Required conditions: The attacker must be able to create or influence a form configured for user updates and provide a target user identifier
- Why exploitation is possible: The update handler trusts the supplied user identifier and passes it to the WordPress user-update API without sufficient ownership or capability validation
Why this happens
The underlying flaw is an authorization failure classified as CWE-269, Improper Privilege Management. The application treats a user-controlled account identifier as sufficient authority to select the account being modified, rather than deriving the target from the authenticated session or verifying an explicit administrative capability. The form-management action also lacks an adequate capability check, allowing lower-privileged users to reach the required update configuration.
Potential impact
- An attacker may change the password or email address of another account
- An administrator account could be taken over
- Unauthorized users could gain elevated privileges
- The WordPress site could be fully compromised
- Site content, settings, or connected data could be altered
General mitigation guidance
Mitigation generally focuses on enforcing authorization at every state-changing
operation and reducing trust in client-supplied identity fields.
Common defensive patterns include:
- Deriving the target account from the authenticated session whenever possible
- Requiring explicit, server-side capability checks for account updates and form management
- Verifying ownership or administrative authority before modifying any user record
- Allowing updates only to narrowly approved fields and applying strong server-side validation
- Protecting sensitive changes with reauthentication, confirmation, or equivalent controls
- Applying least privilege to WordPress roles and limiting access to administrative workflows
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis identifying user-controlled identifiers passed to user-update APIs
- Code review checks for missing capability, ownership, nonce, and authorization validation
- Tests that attempt cross-account updates using lower-privileged roles
- Monitoring AJAX requests that modify passwords, email addresses, roles, or other account attributes
- Policy enforcement requiring centralized authorization checks for all state-changing endpoints
Automated application security and code-review tools may help identify missing authorization controls, but findings should be validated against the deployment's role model.
