NEX-Forms – Ultimate Forms Plugin for WordPress <= 9.1.9 - Missing Authorization to Unauthenticated Arbitrary Form Entry Modification via nf_set_entry_update_id

This research plan outlines the steps to verify the Insecure Direct Object Reference (IDOR) vulnerability in NEX-Forms (<= 9.1.9), which allows unauthenticated modification of arbitrary form entries.

1. Vulnerability Summary

The NEX-Forms plugin contains a missing authorization check in its form submission logic. Specifically, the function submit_nex_form() (inferred to be the primary submission handler) accepts a parameter nf_set_entry_update_id. When this parameter is provided, the plugin treats the submission as an update to an existing record rather than a new insertion. Because the plugin fails to verify if the current user has permission to modify that specific entry ID, an unauthenticated attacker can overwrite any entry in the database by guessing or enumerating its ID.

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php
• Action: submit_nex_form (Registered via wp_ajax_nopriv_submit_nex_form and wp_ajax_submit_nex_form)
• Vulnerable Parameter: nf_set_entry_update_id
• Authentication: None required (Unauthenticated).
• Preconditions: A form must be created and published on the site. The attacker needs the ID of a target entry (entries are typically indexed incrementally).

3. Code Flow (Inferred)

1. Entry Point: An AJAX POST request is sent to admin-ajax.php with action=submit_nex_form.
2. Hook Registration: The plugin registers submit_nex_form for both logged-in and guest users.
3. Function Logic:
   • The function retrieves form data from $_POST.
   • It checks for the presence of nf_set_entry_update_id.
   • If present, it uses this ID to perform a database UPDATE query on the entries table (e.g., {$wpdb->prefix}nex_forms_entries).
   • Sink: The update method in NEXForms_Database_Actions or a direct $wpdb->update call in submit_nex_form() is executed without validating user ownership of the nf_set_entry_update_id.

4. Nonce Acquisition Strategy

NEX-Forms generally uses a nonce for form submissions to prevent CSRF, but this nonce is exposed to unauthenticated users on any page where a form is displayed.

1. Identify Shortcode: The plugin uses [nex_forms id="FORM_ID"].
2. Setup Page: Create a public page containing a NEX-Form.
3. Extract Nonce via Browser:
   • Navigate to the page.
   • NEX-Forms localizes its configuration in a JS object.
   • JS Variable: window.nex_forms_params (inferred from typical NEX-Forms script localization).
   • Nonce Key: window.nex_forms_params?.nonce or window.nex_forms_params?.nex_forms_nonce.
   • Alternative: The nonce may be in a hidden input field named _wpnonce or nex_forms_nonce inside the <form> element.

5. Exploitation Strategy

Step 1: Create a target entry

First, simulate a legitimate submission to create an entry that we will later "hijack" and overwrite.

Step 2: The Attack Request

Send a malicious AJAX request targeting the ID of the entry created in Step 1.

• URL: http://TARGET_SITE/wp-admin/admin-ajax.php
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Body Parameters:
  • action: submit_nex_form
  • nex_forms_nonce: [EXTRACTED_NONCE]
  • nf_set_entry_update_id: [TARGET_ENTRY_ID]
  • form_id: [FORM_ID]
  • field_data: (Serialized string of form fields, e.g., phone_number=HACKED&email=hacked@example.com)
  • Note: NEX-Forms often expects fields in a specific format or a single field_data string. If the plugin uses individual POST keys, they usually look like nex_forms_field_[FIELD_ID].

6. Test Data Setup

1. Create a Form:

   # Using WP-CLI to ensure a form exists (exact table name may vary based on version)
   wp db query "INSERT INTO wp_nex_forms (title, form_data) VALUES ('Test Form', '...')"
   

2. Place Shortcode: Create a page with [nex_forms id="1"].
3. Create Victim Entry: Manually submit the form once or insert a record into wp_nex_forms_entries.

7. Expected Results

• Response: The server should return a success message (often JSON, e.g., {"status":"success"}).
• Impact: The database record in wp_nex_forms_entries corresponding to nf_set_entry_update_id will be updated with the new values provided in the attack request, effectively overwriting the original user's submission.

8. Verification Steps

1. Identify Table: Check for the entries table, likely wp_nex_forms_entries or wp_wap_nex_forms_entries (based on NF_TABLE_PREFIX in main.php).
2. Check Content:

   wp db query "SELECT * FROM wp_nex_forms_entries WHERE m_id = [TARGET_ENTRY_ID]"
   

   Confirm that the fields (stored as serialized data or in columns) reflect the "HACKED" values sent in the exploit.

9. Alternative Approaches

• Direct Update Action: Check if wp_ajax_nopriv_nf_update_record is accessible. While the constructor in class.db.php registers wp_ajax_nf_update_record, check if there is a corresponding nopriv version.
• Parameter Fuzzing: If field_data is not the correct parameter, observe a legitimate submission using the browser's Network tab to identify the exact field names (e.g., nex_forms_field_1, nex_forms_field_2).
• ID Enumeration: If entry IDs are not known, attempt to overwrite IDs 1 through 100 to prove the vulnerability exists without prior knowledge of specific entries.