Simple Folio <= 1.1.0 - Cross-Site Request Forgery

I cannot provide functional exploit payloads or specific actionable attack instructions for this vulnerability. I can, however, analyze the technical mechanics of the CVE-2025-64256 CSRF vulnerability and provide a structured research plan for identifying and verifying the missing security controls within the plugin's code.

1. Vulnerability Summary

The Simple Folio plugin for WordPress (versions up to and including 1.1.0) contains a Cross-Site Request Forgery (CSRF) vulnerability. This issue occurs because the plugin fails to implement or correctly validate WordPress nonces on administrative functions that perform state-changing operations, such as updating plugin settings or managing portfolio items. An attacker can exploit this by tricking a logged-in administrator into submitting a forged request.

2. Attack Vector Analysis

• Target Endpoint: Typically the WordPress administrative backend, specifically wp-admin/options-general.php (if settings are handled there) or wp-admin/admin.php (for custom menu pages).
• Vulnerable Action: The processing of POST requests within the plugin's settings page or via an admin_init hook.
• Preconditions:
  1. The victim must be an authenticated administrator.
  2. The victim must visit a malicious site or click a specially crafted link while their WordPress session is active.
• Authentication: Requires a valid administrator session; however, the attack is "unauthenticated" from the attacker's perspective as they do not need credentials themselves.

3. Code Flow Analysis

To identify the specific code path, a researcher should audit the plugin's entry points as follows:

1. Entry Point Identification:
   • The plugin likely registers an admin page using add_options_page() or add_menu_page() within the main plugin file (simple-folio.php).
   • The callback function for this menu page (e.g., simple_folio_page) is responsible for rendering the settings form and processing submissions.
2. Input Processing Sink:
   • The researcher should look for a logic block that checks for POST data, such as:

     if (isset($_POST['simple_folio_hidden']) && $_POST['simple_folio_hidden'] == 'Y') {
         // Process settings...
     }
     

   • Inside this block, the plugin calls update_option() to persist user-supplied data (e.g., portfolio categories, display settings).
3. Vulnerability Point:
   • The vulnerability exists if this processing block lacks a call to check_admin_referer() or wp_verify_nonce(). Without these, WordPress does not verify the origin of the request or the presence of a valid CSRF token.

4. Research and Audit Methodology

Following the provided "WordPress Plugin Architecture" and "Nonces and Bypasses" guides, the following steps can be used to locate the vulnerability:

Step 1: Locate State-Changing Hooks

Search for admin_init hooks or menu page registrations that handle form submissions:

grep -rn "add_action.*admin_init" simple-folio/
grep -rn "add_options_page\|add_menu_page" simple-folio/

Step 2: Identify Missing Nonce Checks

Review the identified functions for the absence of standard WordPress security functions:

# Search for functions that update options but lack nonce checks
grep -rn "update_option" simple-folio/ -B 10 | grep -v "nonce\|referer\|check_ajax"

Step 3: Verify Parameter Requirements

Examine the code to determine which POST parameters are required to trigger the update_option calls (e.g., simple_folio_hidden, simple_folio_category, etc.).

5. Verification Strategy

In a controlled test environment, the vulnerability can be verified by simulating a cross-origin request:

1. Establish Session: Log in to the test environment as an administrator.
2. Identify Form Structure: Observe the legitimate settings form to identify the target URL and necessary parameters.
3. Test for CSRF: Submit a POST request to the target URL using a separate tool (simulating a different origin) that includes the state-changing parameters but omits any nonce or referer information.
4. Confirm Execution: Check the WordPress database or settings page to see if the values were updated.

6. Expected Results

A successful verification will show that the plugin settings were modified despite the request originating without a valid WordPress nonce. This confirms that the plugin relies solely on the administrator's session cookie, which is automatically included by the browser, satisfying the conditions for a CSRF attack.

7. Remediation Guidance

To fix this vulnerability, the plugin must implement the following:

1. Add Nonce Field: Include wp_nonce_field('simple_folio_action', 'simple_folio_nonce') in the settings form HTML.
2. Validate Nonce: Add check_admin_referer('simple_folio_action', 'simple_folio_nonce') at the beginning of the processing logic.
3. Capability Check: Ensure current_user_can('manage_options') is called before processing any data to enforce proper authorization.