Summary
A critical privilege-escalation vulnerability in the Super Forms – Drag & Drop Form Builder WordPress plugin allows unauthenticated visitors to create accounts with the Administrator role. The issue becomes risky when a published registration form uses the affected Register & Login add-on and accepts a client-controlled role value without authorization checks.
Affected context
The vulnerability occurs in WordPress installations using the Super Forms plugin with the Register & Login add-on and a published registration form. It affects configurations where registration requests reach the vulnerable role-handling logic and the submitted role is copied into the user data passed to WordPress account-creation APIs without being constrained by the configured registration role.
Exploit preconditions
- Attack surface: A publicly accessible Super Forms registration form
- Required access: No authentication is required
- Trigger point: Processing a registration request by the Register & Login add-on
- Why exploitation is possible: A client-submitted
rolevalue is accepted into the user-data structure without an allow-list, comparison with the configured registration role, or a capability check
Why this happens
The underlying bug is improper privilege assignment from untrusted input. The registration handler permits a client-controlled role field to flow into the data passed to wp_insert_user() instead of deriving the role from trusted server-side configuration. This maps to CWE-269, Improper Privilege Management, because an unauthenticated user can influence the privilege level assigned to a newly created account.
Potential impact
- An unauthenticated attacker may create an Administrator account
- Attackers could modify WordPress content, settings, and users
- The site could be used to deploy malicious code or persistent backdoors
- Sensitive site data may be accessed or altered
- The WordPress installation could be used to attack connected systems
General mitigation guidance
Mitigation generally focuses on ensuring that account privileges are derived
from trusted server-side policy rather than registration input.
Common defensive patterns include:
- Ignoring or rejecting client-supplied role fields during public registration
- Applying a strict server-side allow-list of permitted registration roles
- Enforcing the administrator-configured registration role at the final user-creation boundary
- Requiring explicit authorization and capability checks before assigning elevated roles
- Applying least privilege to newly registered accounts and reviewing existing user roles
- Restricting public registration and protecting administrative workflows where appropriate
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis for user-controlled fields flowing into account-creation APIs
- Code review checks for role assignment based on request parameters
- Searches for missing allow-lists, authorization checks, and server-side role enforcement
- Web logs containing unexpected role parameters in registration requests
- Audits of recently created users and changes to privileged WordPress accounts
- Policy checks that require privilege decisions to be made from trusted configuration
