Exploitation Research Plan - CVE-2026-6675

1. Vulnerability Summary

The Responsive Blocks plugin (<= 2.2.0) contains an unauthenticated open email relay vulnerability. The flaw exists within a public WordPress REST API endpoint that handles email functionality (likely associated with a contact form or lead generation block). The endpoint accepts a recipient address via the email_to parameter without verifying that the address belongs to an authorized site administrator or is hardcoded in the block configuration. Consequently, an unauthenticated attacker can use the WordPress site's server to send arbitrary emails to any destination.

2. Attack Vector Analysis

• Endpoint: A REST API route registered under the plugin's namespace (likely responsive-blocks/v1 or responsive-block-editor-addons/v1).
• HTTP Method: POST
• Vulnerable Parameter: email_to
• Authentication: None (Unauthenticated).
• Preconditions: The plugin must be active. The specific block that utilizes this REST route does not necessarily need to be published on a page if the REST API is globally accessible, though a nonce might be required if the permission_callback is tied to one.

3. Code Flow

1. Route Registration: The plugin registers a REST route during the rest_api_init hook using register_rest_route().
2. Missing Authorization: The permission_callback for this route likely returns __return_true or lacks a current_user_can() check.
3. Input Processing: The handler function associated with the route retrieves the email_to parameter from the WP_REST_Request object via $request->get_param('email_to').
4. Sink: The unsanitized/unvalidated email_to value is passed directly as the first argument ($to) to the wp_mail() function.

4. Nonce Acquisition Strategy

REST API endpoints in WordPress often require a wp_rest nonce passed in the _wpnonce parameter or the X-WP-Nonce header.

1. Identify the Script Variable: Search the codebase for wp_localize_script to see where the REST URL and nonce are passed to the frontend.
   • Command: grep -rn "wp_localize_script" .
2. Target Block: The email functionality is likely part of a "Contact Form" or "Newsletter" block. Identify the shortcode or block name.
3. Setup for Extraction:
   • Create a page containing the relevant block: wp post create --post_type=page --post_status=publish --post_content='<!-- wp:responsive-blocks/contact-form /-->'. (The exact block name should be verified via grep -rn "register_block_type" .).
4. Extract via Browser:
   • Navigate to the newly created page using browser_navigate.
   • Execute browser_eval to find the nonce.
   • Example JS: window.responsive_blocks_params?.nonce or window.rb_data?.rest_nonce (Search for exact keys in the source).

Note: If the permission_callback is truly empty or __return_true, a nonce may not be required at all.

5. Exploitation Strategy

1. Locate Endpoint: Search the plugin for the specific REST route.
   • Command: grep -r "register_rest_route" .
   • Look for routes that reference email_to.
2. Determine Parameters: Identify other required parameters (e.g., subject, message, name).
3. Craft the Request:
   • URL: http://<target>/wp-json/responsive-blocks/v1/send-email (inferred route).
   • Headers: Content-Type: application/json
   • Body:

     {
       "email_to": "target-victim@example.com",
       "subject": "Important Security Update",
       "message": "This is an arbitrary message sent via your own server.",
       "reply_to": "attacker@evil.com"
     }
     

4. Execute: Use the http_request tool to send the POST request.

6. Test Data Setup

1. Install and activate responsive-block-editor-addons version 2.2.0.
2. (Optional) Create a page with the contact form block to identify the exact REST parameters used by the legitimate frontend.
   • wp post create --post_type=page --post_title="Contact" --post_status=publish --post_content='<!-- wp:responsive-blocks/contact-form /-->'
3. Ensure WP_DEBUG is enabled to catch any wp_mail errors.

7. Expected Results

• The server should return a 200 OK or 201 Created status code.
• The response body might contain {"success": true} or similar confirmation.
• The WordPress mail system will attempt to deliver an email to target-victim@example.com.

8. Verification Steps

1. Intercept Email: Use wp-cli to check the mail log if a logging plugin (like WP Mail Logging) is installed.
2. Debug Log: Check wp-content/debug.log for any output from the wp_mail filter or errors.
3. Manual Check: If the test environment has a catch-all mailbox (like MailHog), verify the arrival of the email with the attacker-specified subject and body.
4. Code Audit Verification:
   • Verify that the permission_callback in includes/rest-api/class-responsive-blocks-rest-api.php (inferred path) does not check for manage_options or similar capabilities.

9. Alternative Approaches

• Form-Data: If the REST API does not accept JSON, try Content-Type: application/x-www-form-urlencoded.
• Action Parameter: Check if the route is actually a generic one that takes an action parameter to determine which function to run (e.g., ?action=submit_form).
• Default Recipients: If email_to is ignored, check if other parameters like to_email or recipient are used instead. The grep for email_to is the primary source of truth.