RegistrationMagic – Custom Registration Forms, User Registration, Payment, and User Login

RegistrationMagic 5.0.1.8 through 6.0.9.8 does not verify that a Facebook access token was issued for the site's configured application. An unauthenticated attacker with a token for an existing user can log in as that user, or create and enter a new account even when WordPress registration is disabled.

RegistrationMagic 6.0.0.0 through 6.0.9.8 trusts a client-supplied quantity multiplier when calculating paid-registration totals. An unauthenticated visitor can manipulate the value, complete registration without payment, and receive the role configured for that form.

RegistrationMagic before 6.0.9.9 does not validate a paid registration's total on the server. An unauthenticated visitor can complete the registration without paying and receive an activated WordPress account.

RegistrationMagic before 6.0.9.4 inserts an insufficiently sanitized and escaped parameter into an SQL statement. A high-privilege user such as an Administrator can inject SQL into the WordPress database.

RegistrationMagic before 6.0.9.5 verifies only that a submitted PayPal capture reports COMPLETED. It does not bind the capture to the registration by checking amount, currency or payee and does not reject a reused capture. An unauthenticated attacker can use a genuine low-value capture to finalize a more expensive registration, then replay it for additional registrations. The callback endpoint or action, capture-ID parameter and verification and finalization functions are not disclosed.

RegistrationMagic before 6.0.9.4 routes a public request with rm_slug=rm_user_form_edit_sub to RM_Front_Form_Controller::edit_sub(). Attacker-controlled form_id and submission_id values are passed to create_form_prefilled() and save_edited_submission() without authentication, ownership validation or a submission-bound nonce. Submitted field values then replace the selected submission, and update_user_profile() writes the edited profile fields to the non-administrator WordPress account identified by the submitted email address. Version 6.0.9.4 binds the edit to the authorized email, verifies the form/submission owner and a nonce, and rejects privileged user-meta keys.

RegistrationMagic before 6.0.9.4 validates the rm_secure_otp cookie against a front-user record but obtains the authorized identity separately from the attacker-controlled rm_autorized_email cookie. A visitor with a valid RegistrationMagic OTP session for one email can replace the email cookie with another identity, then request the configured front-end submissions page and select a submission_id; RM_Front_Controller::submissions() treats that cookie value as the authorized email and returns the matching user's submission details, including personal information. No WordPress account is required. Version 6.0.9.4 resolves the email from the database row bound to the OTP instead of trusting the separate email cookie.

RegistrationMagic is affected by a security weakness. Exposure depends on how the affected operation is made reachable by the site. The resulting impact depends on how the affected component exposes the vulnerable operation.

RegistrationMagic is affected by a security weakness. Exposure depends on how the affected operation is made reachable by the site. The resulting impact depends on how the affected component exposes the vulnerable operation.

RegistrationMagic – Custom Registration Forms, User Registration, Payment, and User Login is affected by code execution. The vulnerable path is reachable without authentication. Successful exploitation can run attacker-controlled code in the WordPress hosting account.

RegistrationMagic is affected by cross-site scripting. Exposure depends on how the affected operation is made reachable by the site. Injected script can execute in the affected site's origin when the vulnerable output is viewed.

RegistrationMagic is affected by cross-site scripting. Exposure depends on how the affected operation is made reachable by the site. Injected script can execute in the affected site's origin when the vulnerable output is viewed.

RegistrationMagic is affected by a security weakness. Exposure depends on how the affected operation is made reachable by the site. The resulting impact depends on how the affected component exposes the vulnerable operation.

RegistrationMagic – Custom Registration Forms, User Registration, Payment, and User Login is affected by SQL injection. Exploitation requires an authenticated contributor account. A successful request can alter database queries and expose or modify WordPress data.

RegistrationMagic is affected by SQL injection. Exposure depends on how the affected operation is made reachable by the site. A successful request can alter database queries and expose or modify WordPress data.

RegistrationMagic is affected by cross-site scripting. Exposure depends on how the affected operation is made reachable by the site. Injected script can execute in the affected site's origin when the vulnerable output is viewed.

RegistrationMagic is affected by SQL injection. Exposure depends on how the affected operation is made reachable by the site. A successful request can alter database queries and expose or modify WordPress data.

RegistrationMagic is affected by a security weakness. The vulnerable path is reachable without authentication. The resulting impact depends on how the affected component exposes the vulnerable operation.