Exploitation Research Plan - CVE-2025-11924

1. Vulnerability Summary

CVE-2025-11924 is a high-severity Insecure Direct Object Reference (IDOR) vulnerability in the Ninja Forms plugin (versions up to 3.13.2). The vulnerability resides in the ninja-forms-views REST API endpoints.

While the plugin attempted to restrict access via Bearer Tokens, two critical flaws exist:

1. Authorization Bypass: The REST endpoints do not properly verify if the requester has the authority to view metadata or submissions associated with a specific form ID.
2. Token Minting Flaw: A REST API endpoint (introduced in 3.13.1 as a "fix") allows an unauthenticated user to generate a valid bearer token for any arbitrary form_id. This token can then be used to access sensitive submission data and form definitions.

2. Attack Vector Analysis

• Namespace: wp-json/ninja-forms-views/v1 (inferred from "ninja-forms-views").
• Vulnerable Endpoints:
  • Token Minting: Likely a route like GET /ninja-forms-views/v1/token or GET /ninja-forms-views/v1/auth.
  • Data Access: GET /ninja-forms-views/v1/submissions or GET /ninja-forms-views/v1/forms/(?P<id>[\d]+).
• Authentication: Unauthenticated.
• Parameters: form_id (integer).
• Preconditions: The "Submissions Table" block must be active or the REST routes must be registered (default behavior in affected versions).

3. Code Flow

1. Entry Point: An unauthenticated HTTP request is made to the REST API.
2. Route Registration: The plugin registers routes in the ninja-forms-views namespace. Look for register_rest_route in files located in includes/ or a views specific subdirectory.
3. Token Generation: A controller method (likely within a class handling the "Submissions Table" block) generates a JWT or Bearer token using a server-side secret but accepts a user-provided form_id without checking if the user should have access to that form.
4. Data Retrieval: The submissions or metadata endpoint retrieves records from the $wpdb->prefix . 'nf3_submissions' table. It validates the Bearer token's signature but fails to check if the form_id embedded in the token (or provided as a parameter) belongs to the current user (which is 0/unauthenticated).

4. Nonce & Token Acquisition Strategy

Unlike standard AJAX actions, this vulnerability relies on a Bearer Token generated by the REST API itself.

Identifying the Minting Endpoint:

1. Search the codebase for the string ninja-forms-views.
2. Locate where the token is generated. Look for functions using jwt, Bearer, or openssl_encrypt.
3. Identify the specific REST route that calls this function.

Token Extraction via Browser (If needed):

If the token is localized for the block:

1. Create a page with the Ninja Forms Submissions Table block.
2. Identify the localized JS variable. It is likely something like window.nfSubmissionsTable or window.nfViews.
3. Use browser_eval("window.nfViewsConfig?.token") or similar to extract it.

Note: Since 3.13.1 allows minting for "arbitrary form IDs," the primary strategy is to hit the minting endpoint directly via http_request.

5. Exploitation Strategy

Step 1: Discover Form IDs

Iterate through small integers (1, 2, 3...) or use the public-facing REST API to list forms if available.

Step 2: Mint the Bearer Token

Perform an unauthenticated request to the identified minting endpoint.

• URL: http://victimsite.com/wp-json/ninja-forms-views/v1/get-token?form_id=1 (Target endpoint name to be confirmed in source).
• Method: GET
• Expected Response: A JSON object containing a token string.

Step 3: Access Sensitive Information

Use the token to request submissions for the form_id.

• URL: http://victimsite.com/wp-json/ninja-forms-views/v1/submissions?form_id=1
• Method: GET
• Headers: Authorization: Bearer <TOKEN_FROM_STEP_2>
• Expected Response: A JSON array of submission data, including user-submitted field values (PII, messages, etc.).

6. Test Data Setup

To verify the exploit, the environment must contain:

1. A Ninja Form: Create a form with ID 1 using wp-cli.

   # (Simplified) Ninja Forms data is complex; better to use the UI or import a form
   # but the agent can check for existing forms:
   wp db query "SELECT id FROM wp_nf3_forms;"
   

2. Submissions: Ensure the form has at least one submission containing sensitive data (e.g., Email: victim@example.com, Message: SECRET_DATA).
3. Submissions Table Block: Create a post containing the block to ensure all REST routes are initialized.

   wp post create --post_type=page --post_status=publish --post_content='<!-- wp:ninja-forms/submissions-table {"form_id":1} /-->' --post_title='Submissions'
   

7. Expected Results

• Token Minting: The response should return a token string even when no cookies or X-WP-Nonce headers are provided.
• Data Leakage: The final request should return a 200 OK with the full content of the submissions for the requested form_id.

8. Verification Steps

After the HTTP exploit, verify via wp-cli:

1. Compare the data returned by the exploit with the data in the database:

   wp db query "SELECT * FROM wp_nf3_submissions WHERE form_id = 1;"
   wp db query "SELECT * FROM wp_nf3_submission_values WHERE parent_id = (SELECT id FROM wp_nf3_submissions WHERE form_id = 1 LIMIT 1);"
   

2. Check the version of Ninja Forms to ensure it is <= 3.13.2:

   wp plugin get ninja-forms --field=version
   

9. Alternative Approaches

• Metadata Leakage: If submissions are empty, target the form metadata endpoint (/ninja-forms-views/v1/forms/1) to see if internal form configurations (which might include email routing or API keys) are exposed.
• Parameter Brute-forcing: If the token endpoint name is not obvious, use grep -r "register_rest_route" . to find all available routes under the ninja-forms-views namespace.