Google PageRank Display <= 1.4 - Cross-Site Request Forgery to Settings Update via Settings Page

This research plan outlines the methodology for a Proof-of-Concept (PoC) exploitation of CVE-2026-6294, a Cross-Site Request Forgery (CSRF) vulnerability in the Google PageRank Display plugin.

1. Vulnerability Summary

The Google PageRank Display plugin (<= 1.4) fails to implement CSRF protection on its settings page. The core logic resides in the gpdisplay_option() function, which is responsible for both rendering the settings form and processing the updates. Because the form lacks a WordPress nonce field (wp_nonce_field()) and the processing logic lacks validation (check_admin_referer() or wp_verify_nonce()), an attacker can perform state-changing operations (modifying plugin settings) by tricking an authenticated administrator into submitting a forged request.

2. Attack Vector Analysis

• Endpoint: /wp-admin/options-general.php?page=google-pagerank-display (inferred slug based on plugin name).
• Vulnerable Action: POST request to the settings page URL.
• Vulnerable Function: gpdisplay_option()
• Required Authentication: Authenticated Administrator (targeted via CSRF).
• Preconditions: The plugin must be active. An administrator must have an active session and be tricked into visiting a malicious page or clicking a malicious link.

3. Code Flow (Inferred)

1. Registration: The plugin registers a settings page using add_options_page() or add_menu_page() within the admin_menu hook, designating gpdisplay_option as the callback.
2. Entry Point: An administrator visits the settings page or submits the form.
3. Vulnerable Path:
   • The gpdisplay_option() function is invoked.
   • The function likely checks for the presence of a POST variable (e.g., if (isset($_POST['info_update'])) or if (isset($_POST['submit']))).
   • The Vulnerability: It proceeds to update options using update_option() based on the values in $_POST without calling check_admin_referer().
4. Sink: update_option('gpdisplay_style', ...) and other plugin-specific options.

4. Nonce Acquisition Strategy

No nonce is required.
According to the vulnerability description, the plugin is specifically vulnerable because it lacks nonce validation. The gpdisplay_option() function does not verify a nonce before calling update_option(). Therefore, no acquisition strategy is necessary; the exploit will proceed by omitting the nonce entirely.

5. Exploitation Strategy

The goal is to change the gpdisplay_style option to an arbitrary value (e.g., 999 or a string if not properly type-validated).

Step-by-Step Plan:

1. Identify Parameters: Access the plugin settings page as an admin to identify the exact name attributes of the input fields and the submit button.
   • Inferred parameter names: gpdisplay_style, gpdisplay_position, info_update.
2. Craft the Forged Request: Construct a POST request that mimics the legitimate settings update.
3. Execute the Exploit: Use the http_request tool (simulating the administrator's browser context) to send the POST request to the settings endpoint.

HTTP Request Payload (Example):

• URL: http://localhost:8080/wp-admin/options-general.php?page=google-pagerank-display
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Body: gpdisplay_style=2&gpdisplay_position=top_left&info_update=Update+Options (Note: info_update and other keys are inferred and must be verified by the agent inspecting the form).

6. Test Data Setup

1. Plugin Installation: Install and activate google-pagerank-display version 1.4 or lower.
2. Initial State Check: Verify the current value of the plugin's settings using WP-CLI.

   wp option get gpdisplay_style
   

3. Admin User: Ensure an administrator user exists (standard in test environments).

7. Expected Results

• The server should respond with a 302 Redirect (standard WordPress behavior after saving settings) or a 200 OK showing the updated settings page.
• The response should NOT contain any "Are you sure you want to do this?" (WordPress's default "cheatin' uh?" message for failed nonce checks).
• The option in the database should be updated to the value provided in the exploit payload.

8. Verification Steps

After sending the malicious POST request, verify the state change via WP-CLI:

# Check if the style option was successfully changed to the attacker's value
wp option get gpdisplay_style

# Check if other manipulated options were changed
wp option get gpdisplay_position

If the values returned by wp option get match the values sent in the http_request payload, the CSRF is confirmed.

9. Alternative Approaches

If the plugin uses a different slug or different parameter names:

1. Slug Discovery: Run wp eval "echo menu_page_url('google-pagerank-display', false);" or grep the plugin source for add_options_page.
2. Parameter Discovery: Navigate to the settings page using browser_navigate and use browser_eval to extract form field names:

   Array.from(document.querySelectorAll('form input, form select')).map(el => el.name)
   

3. XSS Chain: If the gpdisplay_style or other options are rendered on the frontend without escaping, the CSRF can be elevated to Stored XSS by injecting a script tag into the option value: gpdisplay_style=<script>alert(1)</script>.