Disable Admin Notices – Hide Dashboard Notifications <= 1.4.2 - Cross-Site Request Forgery to Plugin Settings Update

This research plan outlines the steps to verify the Cross-Site Request Forgery (CSRF) vulnerability in the Disable Admin Notices – Hide Dashboard Notifications plugin (CVE-2026-2410).

---

1. Vulnerability Summary

• Vulnerability: Cross-Site Request Forgery (CSRF)
• Plugin: Disable Admin Notices – Hide Dashboard Notifications (disable-admin-notices)
• Affected Versions: <= 1.4.2
• Vulnerable Function: showPageContent()
• Problem: The showPageContent() function, which handles the rendering and saving of plugin settings, fails to perform nonce validation (e.g., check_admin_referer()) before processing $_POST data. This allows an attacker to update plugin settings—specifically the list of blocked URLs or dashboard notifications—by tricking an authenticated administrator into submitting a forged request.

2. Attack Vector Analysis

• Endpoint: wp-admin/options-general.php?page=disable-admin-notices (standard WordPress admin settings page).
• HTTP Method: POST
• Authentication Level: Requires an active Administrator session (exploited via CSRF).
• Payload Parameter: Inferred parameter names based on plugin functionality include dan_url_to_block or settings arrays like dan_settings[blocked_urls]. (The agent will verify the exact key in the Test Data Setup).
• Preconditions: The administrator must be logged into the WordPress dashboard and be tricked into visiting a malicious page or clicking a link that triggers the POST request.

3. Code Flow

1. Entry Point: The plugin registers an admin menu page via add_options_page() in its main class/file. The callback for this menu item is showPageContent.
2. Hook: admin_menu or admin_init.
3. Vulnerable Logic (showPageContent):
   • The function is invoked when visiting the settings page.
   • It typically contains logic like: if ( isset( $_POST['submit'] ) ) { ... update_option( ... ); ... }.
   • Missing Sink: Between the isset($_POST) check and the update_option() call, there is no check_admin_referer() or wp_verify_nonce() call.
4. Sink: update_option() updates the blocked redirects/notices list in the wp_options table.

4. Nonce Acquisition Strategy

No nonce is required for this exploit.
The vulnerability is defined by the absolute absence of nonce validation in the processing path. The attacker does not need to bypass a nonce check; they simply omit it.

5. Exploitation Strategy

The exploitation will simulate an admin being CSRF'd.

1. Discovery: Navigate to the plugin settings page as an admin to identify the exact field names used in the form.
2. Payload Construction: Craft a POST request that targets the settings update logic.
3. Execution: Use the http_request tool with the admin's cookies to submit the forged request.

Target Request (Hypothetical):

• URL: http://[target-ip]/wp-admin/options-general.php?page=disable-admin-notices
• Method: POST
• Content-Type: application/x-www-form-urlencoded
• Body:

  dan_url_to_block=http://malicious-site.com/evil&submit=Save+Changes
  

  (Note: The actual parameter key will be confirmed during the Discovery step).

6. Test Data Setup

1. Install Plugin: Install and activate disable-admin-notices version 1.4.2.
2. Create Admin: Ensure a standard administrator account exists.
3. Discovery Step (Agent Action):
   • Use browser_navigate to wp-admin/options-general.php?page=disable-admin-notices.
   • Use browser_eval to inspect the form:

     Array.from(document.querySelectorAll('form input, form textarea')).map(i => i.name)
     

   • Identify the field responsible for "blocked redirects" or "URLs".

7. Expected Results

• The http_request should return a 302 Redirect or a 200 OK (if the plugin renders the page immediately after saving).
• The WordPress database should be updated with the provided "malicious" URL in the plugin's configuration option.

8. Verification Steps

After the POST request, verify the change using WP-CLI:

1. Identify the Option Name: (Likely dan_settings or disable_admin_notices_blocked).

   wp option list --search="*disable*"
   

2. Check Value:

   wp option get [OPTION_NAME]
   

   • Success Condition: The output contains the URL provided in the exploit payload (e.g., http://malicious-site.com/evil).

9. Alternative Approaches

• If the plugin uses AJAX: If the settings are saved via admin-ajax.php instead of a standard form post, the action name must be identified (e.g., action=dan_save_settings). The http_request tool would then target wp-admin/admin-ajax.php.
• If multiple fields are required: The agent should capture all input[type="hidden"] fields from the form during discovery and include them in the POST body, excluding any that look like nonces (to prove they aren't needed).