Jupiter X Core <= 4.14.1 - Authenticated (Subscriber+) Stored Cross-Site Scripting

This plan outlines the research and exploitation process for CVE-2026-39491 (Stored XSS) in the Jupiter X Core plugin.

1. Vulnerability Summary

The Jupiter X Core plugin (versions <= 4.14.1) contains a stored cross-site scripting vulnerability. The issue stems from an AJAX handler intended for theme or layout settings that fails to verify administrative capabilities and does not sanitize input before saving it to the database. Specifically, a subscriber-level user can trigger an AJAX action to update plugin settings or metadata. When these settings are rendered on the frontend or in the admin dashboard, the malicious script executes.

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php
• Action: jupiterx_core_cp_save_settings or jupiterx_core_save_layout_settings (inferred from common Jupiter X Core AJAX patterns).
• Vulnerable Parameter: Likely a nested array within a settings or data parameter (e.g., settings[breadcrumb_text] or settings[footer_content]).
• Authentication: Required (Subscriber-level or higher).
• Preconditions: The plugin must be active, and the attacker must have valid subscriber credentials.

3. Code Flow (Inferred)

1. Registration: The plugin registers an AJAX action for authenticated users:
   add_action( 'wp_ajax_jupiterx_core_cp_save_settings', 'jupiterx_core_cp_save_settings_callback' );
2. Entry Point: jupiterx_core_cp_save_settings_callback() (in includes/control-panel/2.0/includes/ajax.php) is called.
3. Verification Gap: The function likely checks a nonce but fails to call current_user_can( 'manage_options' ).
4. Source: The function retrieves raw data from $_POST['settings'].
5. Sink (Storage): The data is passed to update_option( 'jupiterx_settings', $settings ) or update_post_meta() without sanitization.
6. Sink (Output): When a page is loaded, the plugin retrieves the setting and echoes it:
   echo get_option( 'jupiterx_settings' )['vulnerable_field']; (missing esc_html or esc_attr).

4. Nonce Acquisition Strategy

Jupiter X Core typically localizes nonces for its Control Panel (CP) in a global JavaScript object.

1. Identify Script Loading: The Control Panel scripts load on the Jupiter X dashboard page.
2. Setup: Create a Subscriber user and log in.
3. Navigation: Navigate to /wp-admin/admin.php?page=jupiterx (or the default plugin landing page accessible to users).
4. Extraction: Use browser_eval to extract the nonce:
   • Variable Name: window.jupiterx_core_cp (inferred).
   • Key: nonce.
   • Command: browser_eval("window.jupiterx_core_cp?.nonce").

5. Exploitation Strategy

1. Login: Authenticate as a Subscriber user via the http_request tool.
2. Nonce Retrieval: Navigate to the Jupiter X dashboard and extract the jupiterx_core_cp.nonce as described above.
3. Craft Payload: Create a JSON or URL-encoded payload that targets a setting reflected on the site header or breadcrumbs.
   • Payload: <img src=x onerror=alert("XSS_EXPLOITED")>
4. Submit Request: Use http_request to send a POST request to admin-ajax.php.

   POST /wp-admin/admin-ajax.php HTTP/1.1
   Content-Type: application/x-www-form-urlencoded
   
   action=jupiterx_core_cp_save_settings&nonce=[EXTRACTED_NONCE]&settings[breadcrumb_custom_text]=<img src=x onerror=alert('XSS_EXPLOITED')>
   

5. Trigger: Navigate to the site's homepage or any post where breadcrumbs/settings are displayed.

6. Test Data Setup

1. Users:
   • admin (Administrator)
   • attacker (Subscriber)
2. Plugin Configuration: Ensure the "Breadcrumbs" or "Custom Layouts" feature is enabled in Jupiter X settings so the injected meta/option is actually rendered on the frontend.
3. Content: Create at least one public post to view the breadcrumb/header output.

7. Expected Results

• Success Response: The AJAX request should return a JSON success message (e.g., {"success": true}).
• Persistence: The malicious payload should be visible in the database under the jupiterx_settings option.
• Execution: When viewing the frontend, a JavaScript alert box with "XSS_EXPLOITED" should appear.

8. Verification Steps

1. Database Check: Use WP-CLI to verify the stored value:
   wp option get jupiterx_settings
2. Frontend Check: Use http_request (GET) on the homepage and check if the raw payload exists in the HTML:
   grep "XSS_EXPLOITED" response_body.html
3. Admin Check: Log in as an Administrator and navigate to the plugin settings page to see if the script executes in the admin context (more critical impact).

9. Alternative Approaches

• Elementor Widget Settings: If the cp_save_settings action is not the culprit, investigate the jupiterx_core_save_elementor_template action. This often allows users to save widget configurations. A subscriber might be able to save a "Custom HTML" widget to a global section.
• Meta Injection: Try the action jupiterx_core_save_post_meta (inferred) if the plugin allows subscribers to edit theme-specific metadata for their own posts, which then fails to escape on output.
• Payload Variations:
  • "><script>alert(1)</script> (to break out of attribute quotes).
  • javascript:alert(1) (if the payload is injected into a URL/href field).