Breakdance <= 2.7.1 - Unauthenticated Stored Cross-Site Scripting

This research plan outlines the investigation and proof-of-concept exploitation for CVE-2026-57735, an unauthenticated stored cross-site scripting vulnerability in the Breakdance plugin.

1. Vulnerability Summary

The Breakdance plugin (<= 2.7.1) contains a vulnerability where an unauthenticated endpoint (likely an AJAX or REST API handler) accepts user-controlled data and stores it in the WordPress database (e.g., in wp_options or wp_postmeta) without sufficient sanitization. When a user (frontend visitor or admin) subsequently navigates to a page rendered by the plugin, this data is output without proper escaping, leading to the execution of arbitrary JavaScript.

2. Attack Vector Analysis

• Vulnerable Endpoint: Likely a wp_ajax_nopriv_ action or an unauthenticated REST API route (registered via register_rest_route with permission_callback set to __return_true).
• Vulnerable Action (Inferred): breakdance_save_form_entry or breakdance_update_element_data.
• Payload Parameter (Inferred): data, content, or specific form field parameters (e.g., form_fields[0][value]).
• Authentication: None required (unauthenticated).
• Preconditions: The plugin must be active. The exploit is most effective if the attacker can target a specific page ID or a global setting used across the site.

3. Code Flow (Inferred)

1. Entry: An unauthenticated user sends a POST request to wp-admin/admin-ajax.php with a specific action (e.g., wp_ajax_nopriv_breakdance_save_submission) or a POST to a Breakdance-specific REST route.
2. Processing: The handler function (e.g., Breakdance\Forms\handle_submission) receives the input. It may perform a weak nonce check (or none at all).
3. Storage: The handler calls update_post_meta() or add_option() to store the input. Crucially, it fails to use wp_kses() or sanitize_text_field() on the data before storage.
4. Sink: When a page is loaded, the plugin retrieves this data using get_post_meta() or get_option() and renders it to the page using echo or printf without context-appropriate escaping functions like esc_html() or esc_attr().

4. Nonce Acquisition Strategy

To bypass potential CSRF protections in unauthenticated handlers, we must extract the nonce from the frontend.

1. Identify the Trigger: Determine which shortcode or element enqueues the Breakdance AJAX script. (Inferred: [breakdance_form] or generic page rendering).
2. Setup:
   • wp post create --post_type=page --post_status=publish --post_title='Contact' --post_content='[breakdance_form]'
3. Extraction:
   • Navigate to the newly created page.
   • Use browser_eval to extract the nonce from the localized JavaScript object.
   • Inferred JS Variable: window.BreakdanceConfig?.nonce or window.breakdanceData?.ajaxNonce.
4. Verification: Compare the action string in wp_create_nonce (found in the source) with the one required by the AJAX handler.

5. Exploitation Strategy

We will attempt to inject a payload into a form submission or element update that is reflected globally or on a specific page.

• Tool: http_request
• Method: POST
• URL: {{base_url}}/wp-admin/admin-ajax.php
• Headers: Content-Type: application/x-www-form-urlencoded
• Parameters:
  • action: breakdance_save_submission (Inferred)
  • nonce: {{extracted_nonce}}
  • data: {"fields": {"message": "<img src=x onerror=alert(document.domain)>"}} (Inferred JSON structure)

Step-by-Step:

1. Reconnaissance: Use grep -r "wp_ajax_nopriv" wp-content/plugins/breakdance/ to find the exact action name and handler function.
2. Payload Crafting: Identify if the input is expected as a raw POST parameter or a JSON-encoded string.
3. Submission: Execute the http_request with the XSS payload.
4. Trigger: Navigate to the page where submissions are displayed (frontend or admin dashboard) to trigger the script.

6. Test Data Setup

1. Plugin Installation: Ensure Breakdance 2.7.1 is installed and active.
2. Target Page: Create a page that uses a Breakdance element (e.g., a Form or a Dynamic Text element).
   • wp post create --post_type=page --post_status=publish --post_content='[breakdance_form id="123"]'
3. Attacker User (Optional): None needed for unauthenticated exploit, but a "Subscriber" user can be used to test if the "nopriv" handler is truly open.

7. Expected Results

• Response: The AJAX/REST request should return a 200 OK or a success JSON message (e.g., {"success": true}).
• Execution: Upon visiting the affected page, a browser alert showing the document domain should appear, confirming JavaScript execution in the context of the site.

8. Verification Steps

1. Database Check: Use WP-CLI to verify the payload is stored in the database.
   • wp post meta list {{post_id}} --keys=_breakdance_submissions (Inferred meta key)
2. DOM Inspection: Use browser_navigate and browser_eval("document.body.innerHTML") to check if the raw <script> or onerror attribute exists in the rendered HTML without being escaped to <.

9. Alternative Approaches

• REST API Path: If admin-ajax.php is protected, check wp-json/breakdance/v1/save-submission. REST routes often lack the same default protections as the AJAX API.
• SVG Injection: If the plugin allows unauthenticated file uploads or "media" selection via AJAX, attempt to upload an SVG containing an XSS payload (see Knowledge Base).
• Shortcode Attribute Injection: If an unauthenticated user can influence how a shortcode is rendered (e.g., through a query parameter that populates a shortcode attribute), test for XSS in the attribute output.