Research Plan: CVE-2026-0929 - RegistrationMagic Missing Authorization

1. Vulnerability Summary

The RegistrationMagic plugin (versions prior to 6.0.7.2) contains a missing capability check in one of its AJAX handlers. This vulnerability allows an authenticated user with Subscriber-level permissions to execute a function intended for administrators. In the context of RegistrationMagic, this typically involves administrative actions such as modifying user metadata, managing form submissions, or altering plugin configurations.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Method: POST
• Action (Inferred): The vulnerability likely resides in an action registered via wp_ajax_ that lacks a current_user_can() check. Based on similar vulnerabilities in this plugin, candidate actions often involve rm_ prefixes, such as rm_save_submission_field, rm_login_view_sett, or actions within the RM_Main_Ajax class.
• Payload Parameters: action=[VULNERABLE_ACTION], [NONCE_PARAM]=[NONCE_VALUE], and data parameters (e.g., user_id, meta_key, config_data).
• Authentication: Subscriber-level (Logged-in) is required.
• Precondition: A valid nonce for the specific AJAX action is usually required, even if the capability check is missing.

3. Code Flow (Inferred)

1. Entry Point: An AJAX request is sent to admin-ajax.php with a specific action parameter.
2. Hook Registration: The plugin registers the action in a core file (likely public/class_rm_public.php or admin/class_rm_admin.php) using:
   add_action('wp_ajax_rm_some_admin_action', array($this, 'callback_function'));
3. Vulnerable Callback: The callback_function is executed.
4. Authorization Failure: The function may check a nonce using check_ajax_referer but fails to call current_user_can('manage_options') or a similar capability check.
5. Sink: The function performs a privileged operation (e.g., update_option, wp_update_user, or database modification via $wpdb).

4. Nonce Acquisition Strategy

RegistrationMagic heavily uses localized scripts to pass nonces to the frontend.

1. Identify Localized Data: Search the plugin source for wp_localize_script.
   • Target: grep -rn "wp_localize_script" .
   • Common variable names: rm_ajax_objects, rm_admin_vars, or rm_data.
2. Determine Nonce Key: Look for the key associated with the vulnerable action.
   • Example: window.rm_ajax_objects?.nonce or window.rm_admin_vars?.rm_nonce.
3. Setup Page for Extraction:
   • Create a page containing a RegistrationMagic shortcode (e.g., [RM_Form id='1']) to ensure the plugin's JS and nonces are loaded.
   • wp post create --post_type=page --post_status=publish --post_content='[RM_Form id="1"]' --post_title='Exploit Research'
4. Browser Extraction:
   • Navigate to the newly created page as a Subscriber user.
   • Execute: browser_eval("window.rm_ajax_objects.nonce") (Verify exact object name in source).

5. Exploitation Strategy

Step 1: Discovery (Identification of the exact sink)

Search for AJAX actions that perform sensitive tasks but lack capability checks:

grep -rn "add_action.*wp_ajax_" . | grep -v "nopriv"

Examine the callback functions for those actions. Look for ones that DO NOT contain current_user_can.

Step 2: Payload Construction

Assuming a common pattern where an administrative action is exposed (e.g., updating a setting):

• URL: http://[TARGET]/wp-admin/admin-ajax.php
• Headers: Content-Type: application/x-www-form-urlencoded, Cookie: [Subscriber_Cookies]
• Body:
  action=[VULNERABLE_ACTION]&security=[NONCE]&param_name=[VALUE]

Step 3: Execution

Use the http_request tool to send the POST request.

6. Test Data Setup

1. Create Subscriber User:
   wp user create attacker attacker@example.com --role=subscriber --user_pass=password123
2. Identify/Create a Form:
   wp plugin get custom-registration-form-builder-with-submission-manager
   (Check if any default forms exist; if not, use RegistrationMagic's UI or CLI if available to create a simple form).
3. Publish Page:
   Place the form shortcode on a public-facing page to ensure the Subscriber can access it and get the nonce.

7. Expected Results

• Response: The server returns a 200 OK (often with a JSON success message or 1) instead of a 403 Forbidden or 0.
• Side Effect: The administrative action (e.g., a setting change or user meta update) is successfully performed despite the requester being a Subscriber.

8. Verification Steps

1. Check Plugin State: Use WP-CLI to verify if the unauthorized change persisted.
   • wp option get [modified_option_name]
   • wp user meta get [target_user_id] [modified_meta_key]
2. Log Review: Check the error_log if the exploit triggered any PHP notices that confirm the execution path.

9. Alternative Approaches

• Parameter Polarity: If the direct action is not obvious, look for "gateway" AJAX handlers (e.g., rm_admin_action) that take a sub-action parameter. These often route to multiple functions, some of which may be missing checks.
• Submission Manipulation: If the vulnerability is in the submission manager, try modifying the status or user_role associated with a form submission to elevate the attacker's privileges upon form approval.
• Search Patterns:

  # Find all AJAX callbacks
  grep -r "function .*Ajax" .
  # Look for missing capability checks in those files
  grep -L "current_user_can" [file_paths]