RTMKit <= 2.0.7 - Authenticated (Contributor+) Missing Authorization to Arbitrary Form Submission Access via 'entries_id' Parameter

This exploitation research plan focuses on CVE-2026-5149, an Incorrect Authorization vulnerability in the RTMKit (RomeThemeKit) plugin for WordPress.

---

1. Vulnerability Summary

The RTMKit plugin (versions ≤ 2.0.7) registers an AJAX endpoint get_submission_content (likely within the SubmissionModule) that is intended to retrieve form submission data. The vulnerability arises because this endpoint fails to perform a capability check (e.g., current_user_can('manage_options')) or an ownership check on the requested data.

Authenticated users with Contributor-level permissions or higher can exploit this to view arbitrary form submissions—potentially containing sensitive PII (Personally Identifiable Information)—by iterating through the entries_id parameter.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: get_submission_content (Inferred AJAX action)
• Vulnerable Parameter: entries_id
• Authentication: Authenticated (Contributor+)
• Required Header: Content-Type: application/x-www-form-urlencoded
• Nonce Action: rtmkit_nonce (Required by the plugin's API pattern)

3. Code Flow

While the specific source for the SubmissionModule is truncated, the execution flow is grounded in the provided PluginApi.php and Plugin.php files:

1. Registration: The Plugin class initializes SubmissionModule (Line 183 of Plugin.php).
2. AJAX Hook: The module likely registers wp_ajax_get_submission_content.
3. Vulnerable Handler: The handler function (likely get_submission_content) is invoked.
4. Insecure Authorization: Unlike PluginApi::get_content() (which checks for manage_options), the submission handler fails to verify if the current user should have access to the entry identified by $_POST['entries_id'].
5. Data Sink: The code queries the database for the submission corresponding to the ID and returns the content via wp_send_json_success().

4. Nonce Acquisition Strategy

The plugin uses a nonce check: check_ajax_referer('rtmkit_nonce', 'nonce'). To obtain a valid nonce as a Contributor:

1. Identify Trigger: The nonce is likely localized for the "System Panel" or the Form Submission management area in the admin dashboard.
2. Setup Page: A Contributor can access the WordPress admin dashboard.
3. Extraction:
   • Navigate to the RTMKit dashboard or a page where the plugin's admin scripts are loaded (e.g., /wp-admin/admin.php?page=rtmkit).
   • Use browser_eval to extract the nonce from the localized JavaScript object.
   • Inferred Variable: Based on the script handle rtmkit-system-panel, the variable is likely rtmkit_panel_vars or similar.
   • Command: browser_eval("window.rtmkit_panel_vars?.nonce") or search for rtmkit_nonce in the global scope.

5. Exploitation Strategy

The goal is to demonstrate unauthorized access to a form submission created by another user (e.g., an Admin or a public visitor).

Step 1: Authenticate
Authenticate as a Contributor-level user.

Step 2: Nonce Retrieval
Fetch the nonce using the strategy in Section 4.

Step 3: Data Iteration
Send a series of POST requests to retrieve submissions.

• Request URL: http://localhost:8080/wp-admin/admin-ajax.php
• Method: POST
• Body:

  action=get_submission_content&nonce=[NONCE]&entries_id=[ID]
  

• Example Payload (entries_id=1):

  action=get_submission_content&nonce=a1b2c3d4e5&entries_id=1
  

Step 4: Analyze Response
A successful exploit will return a JSON object with success: true and the submission data in the data field, even if the user is not an admin.

6. Test Data Setup

1. Form Creation: Create a form using the RTMKit Form widget (requires Elementor).
2. Submission: Submit the form as an unauthenticated visitor or an Admin user with test data (e.g., email: admin-secret@example.com).
3. User Creation: Create a user with the Contributor role.
4. Note ID: Identify the ID of the submission in the database (e.g., via wp_rtmkit_submissions table) to target it specifically.

7. Expected Results

• Unauthorized Access: The Contributor receives the full content of the submission (e.g., name, email, message) in the JSON response.
• HTTP 200 OK: The server returns a successful response instead of an "Access Denied" error or 403 status.

8. Verification Steps

After the HTTP request, verify the vulnerability using WP-CLI:

1. Check Capability: Verify that the current user lacks the manage_options capability:
   wp user cap list [CONTRIBUTOR_ID]
2. Compare Data: Verify that the data returned in the AJAX response matches the data stored in the database for that entries_id:
   wp db query "SELECT * FROM wp_rtmkit_submissions WHERE id = [ID]" (Note: Table name is inferred).

9. Alternative Approaches

• Direct Parameter Manipulation: If entries_id is not the only parameter, check for entry_id or submission_id.
• GET Request: While check_ajax_referer usually looks at $_REQUEST, try sending the payload via GET if POST is blocked, as some plugins do not restrict the method.
• ID Brute-forcing: If a specific ID is unknown, use a loop to iterate IDs from 1 to 500 to discover existing submissions.