Exploitation Research Plan: CVE-2026-2714 - Institute Management Stored XSS

1. Vulnerability Summary

The Institute Management plugin (<= 5.5) for WordPress contains a stored cross-site scripting (XSS) vulnerability via the 'Enquiry Form Title' setting. The plugin fails to sanitize the input when saving this setting and fails to escape the output when rendering it on the frontend or backend. While the vulnerability requires Administrator-level privileges, it is significant in Multi-site environments or hardened installations where the unfiltered_html capability is disabled for administrators.

2. Attack Vector Analysis

• Endpoint: WordPress Admin Dashboard, specifically the plugin's settings page.
• Vulnerable Setting: Enquiry Form Title (likely stored as a WordPress option).
• HTTP Parameter: Likely a POST parameter named enquiry_form_title or similar (inferred).
• Authentication: Required (Administrator+).
• Preconditions:
  • The environment must be a Multi-site installation OR have define( 'DISALLOW_UNFILTERED_HTML', true ); in wp-config.php to prevent the administrator from having legitimate unfiltered_html rights.
  • A page must exist that renders the Enquiry Form (often via a shortcode).

3. Code Flow (Inferred)

1. Input Stage: The administrator navigates to the "Institute Management" settings menu (e.g., wp-admin/admin.php?page=institute-management-settings).
2. Persistence Stage: Upon clicking "Save", a POST request is sent. A handler (likely registered via admin_init or admin_menu) receives the data and calls update_option( 'wl_im_enquiry_form_title', $_POST['enquiry_form_title'] ) without using sanitize_text_field.
3. Rendering Stage: A user (or admin) visits a page containing the enquiry form. The plugin calls get_option( 'wl_im_enquiry_form_title' ) and outputs it directly using echo or printf without esc_html() or wp_kses().

4. Nonce Acquisition Strategy

Since this involves an administrative settings page, a CSRF nonce is almost certainly required.

1. Identify the Settings Page: Locate the menu slug for the plugin (e.g., institute-management or wl-im-settings).
2. Navigate via Browser: Use browser_navigate to go to http://localhost:8080/wp-admin/admin.php?page=institute-management-settings.
3. Extract Nonce: Use browser_eval to extract the nonce from the settings form.
   • Target Variable: Look for the hidden input field usually named _wpnonce or a specific action nonce (e.g., wl_im_settings_nonce).
   • Command: browser_eval("document.querySelector('input[name=\"_wpnonce\"]')?.value") or check for localized JS variables.

5. Exploitation Strategy

Step 1: Discover the exact setting field

Navigate to the settings page and inspect the form to identify the exact name of the input field for "Enquiry Form Title".

Step 2: Inject Payload

Submit a POST request to the settings handler (likely options.php if using the Settings API, or the current page if using a custom handler).

Example Request (assuming Settings API):

• URL: http://localhost:8080/wp-admin/options.php
• Method: POST
• Content-Type: application/x-www-form-urlencoded
• Body:

  option_page=institute_management_settings_group&
  wl_im_enquiry_form_title=<script>alert(document.domain)</script>&
  action=update&
  _wpnonce=[EXTRACTED_NONCE]
  

Step 3: Trigger Execution

Identify the shortcode or frontend page where the enquiry form is displayed.

1. Create a page with the enquiry shortcode: wp post create --post_type=page --post_status=publish --post_content='[wl_im_enquiry_form]' (shortcode inferred from plugin slug).
2. Use browser_navigate to visit that page.
3. Observe if the script <script>alert(document.domain)</script> executes.

6. Test Data Setup

1. Hardening: Disable unfiltered_html in wp-config.php to ensure the test reflects the vulnerability context.
   • wp config set DISALLOW_UNFILTERED_HTML true --raw
2. User: Create an administrator user.
3. Shortcode Page:
   • wp post create --post_title="Enquiry" --post_content="[wl_im_enquiry_form]" --post_status="publish" --post_type="page"
   • (Note: Search the plugin code for add_shortcode to find the exact tag).

7. Expected Results

1. The settings page accepts the payload without sanitization.
2. When the frontend page is loaded, the HTML source contains the raw <script> tag rather than the escaped <script>.
3. The browser triggers an alert or executes the injected JS logic.

8. Verification Steps

1. Database Check: Use WP-CLI to verify the stored value is not sanitized.
   • wp option get wl_im_enquiry_form_title (verify it returns the raw <script> tag).
2. Response Check: Use http_request to fetch the frontend page and check for the presence of the unescaped payload.
   • grep "<script>alert(document.domain)</script>" in the response body.

9. Alternative Approaches

• Custom Post Meta: If the title is not a global setting but a per-form setting, the exploit would involve modifying a specific post meta via the form builder interface.
• Admin XSS: The title might also be reflected back on the settings page itself. If the settings page shows the "Current Title", the XSS would execute every time the administrator visits the settings page, creating a self-reinforcing admin-context exploit.
• Blind XSS: If the enquiry is sent to an admin dashboard, the payload might execute when an admin views the submitted enquiry in the backend. Look for wl_im_enquiries or similar management pages.