VPSUForm <= 3.2.24 - Authenticated (Contributor+) Information Exposure

This research plan focuses on identifying and exploiting an information exposure vulnerability in VPSUForm <= 3.2.24. Since source files were not provided, this plan incorporates discovery steps to pinpoint the exact vulnerable endpoint, based on common patterns in WordPress form builder plugins and the "Contributor+" requirement.

---

1. Vulnerability Summary

The VPSUForm plugin suffers from an information exposure vulnerability where authenticated users with Contributor-level permissions can access sensitive data (such as form submissions, plugin configurations, or user metadata) that should be restricted to Administrators. This typically occurs because an AJAX or REST API handler performs a nonce check (verifying the request is from the site) but fails to perform a capability check (verifying the user has manage_options or similar rights).

2. Attack Vector Analysis

• Endpoint: Likely a WordPress AJAX action (/wp-admin/admin-ajax.php) or a REST API route (/wp-json/v-form/v1/...).
• Vulnerable Action (Inferred): Look for actions like v_form_get_entries, v_form_export_data, or v_form_fetch_settings.
• Authentication: Contributor-level session cookies required.
• Preconditions:
  1. The plugin must be active.
  2. At least one form must exist with submissions (to demonstrate PII exposure) or sensitive settings (API keys) must be configured.
  3. A valid nonce associated with the plugin's admin functions.

3. Code Flow (Inferred Trace)

1. Entry Point: wp_ajax_{action} hook is registered in the plugin's main class or an AJAX handler class (e.g., includes/class-vform-ajax.php).
2. Nonce Verification: The handler likely calls check_ajax_referer( 'vform_admin_nonce', 'nonce' ) or similar. Since a Contributor can access the admin dashboard, they can often trigger the script enqueuing that generates this nonce.
3. Missing Capability Check: The code proceeds to fetch data from the database (e.g., $wpdb->get_results("SELECT * FROM {$wpdb->prefix}vform_entries")) without calling current_user_can('manage_options').
4. Data Sink: The handler returns the data via wp_send_json_success(), exposing it to the Contributor.

4. Nonce Acquisition Strategy

The plugin likely localizes a nonce for its admin interface. Since Contributors have access to the /wp-admin/ area, we can extract the nonce from the dashboard.

1. Identification: Search the plugin code for wp_localize_script to find the JavaScript object name.
   • Search command: grep -r "wp_localize_script" .
   • Likely Variable: vform_admin or vform_vars.
2. Acquisition via Browser:
   1. Log in as a Contributor.
   2. Navigate to /wp-admin/.
   3. Check if the plugin enqueues scripts on the dashboard. If not, check if there is a specific plugin page a Contributor can see.
   4. Run: browser_eval("window.vform_admin?.nonce") (Replace vform_admin and nonce with actual keys found during search).

5. Exploitation Strategy

Step 1: Discover the Vulnerable Action

The agent should first identify all registered AJAX actions:

grep -rn "wp_ajax_" .

Look for actions that don't have a corresponding wp_ajax_nopriv_ (meaning they are authenticated-only) and investigate their handlers for capability checks.

Step 2: Extract Nonce and Target Action

Once an action (e.g., v_form_get_entries) and a nonce key (e.g., vform_nonce) are identified:

Step 3: Perform Information Extraction

Use the http_request tool to simulate the Contributor's request.

Request Template:

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

  action=v_form_get_entries&nonce=[EXTRACTED_NONCE]&form_id=1
  

6. Test Data Setup

To confirm information exposure, we need data to "leak":

1. Create a Form: Use WP-CLI or the plugin UI to create a simple contact form.
2. Submit Data: Submit dummy PII (name, email, phone) to the form.
3. Create Attacker:

   wp user create attacker attacker@example.com --role=contributor --user_pass=password123
   

4. Add Sensitive Settings: If the plugin has an "API Keys" section, populate it with a fake key.

7. Expected Results

• Vulnerable Response: An HTTP 200 JSON response containing an array of form submissions, including the dummy PII or sensitive plugin settings.
  • Example: {"success":true,"data":[{"id":"1","form_id":"1","data":"{\"email\":\"victim@target.com\",\"message\":\"Top Secret\"}"}]}
• Secure Response: An HTTP 403 Forbidden or an error message like {"success":false,"data":"You do not have permission to view this."}.

8. Verification Steps

After the exploit attempt:

1. Check JSON Output: Parse the response from http_request to ensure it contains strings matching the dummy PII created in Step 6.
2. Verify DB Content: Use WP-CLI to confirm the leaked data matches the database:

   wp db query "SELECT * FROM wp_vform_entries LIMIT 1;"
   

9. Alternative Approaches

• REST API Discovery: If no AJAX actions are obviously vulnerable, check for REST routes: grep -r "register_rest_route" .. Check if permission_callback returns __return_true or only checks is_user_logged_in().
• Direct Parameter Fuzzing: If form_id is required, iterate through common IDs (1, 2, 3) to find active forms.
• Export Bypass: Check if the plugin has a CSV export feature that can be triggered via admin-post.php or admin-ajax.php without capability checks. Look for fputcsv or header('Content-Type: text/csv').