Exploitation Research Plan: CVE-2026-12428

This plan outlines the systematic approach to exploiting a Missing Authorization vulnerability in the Blocks for ACF Fields plugin (<= 1.6.2), which allows authenticated users (Author level and above) to disclose arbitrary Advanced Custom Fields (ACF) values from any post or object ID.

1. Vulnerability Summary

• Vulnerability: Missing Authorization
• Location: inc/class-rest.php (specifically the get_all_values() callback for the /wp-json/acf-field-blocks/v1/values REST endpoint).
• Cause: The permission_callback for the /values endpoint only verifies the publish_posts capability. The implementation of get_all_values() (as described in the vulnerability report and supported by the Rest::register_routes structure) accepts a user-controlled id parameter and passes it to ACF functions (like get_field_objects()) without verifying if the current user has permission to read the specific post associated with that id.

2. Attack Vector Analysis

• REST Endpoint: /wp-json/acf-field-blocks/v1/values
• HTTP Method: GET (READABLE)
• Vulnerable Parameter: id (Target Post/Object ID)
• Authentication Required: Authenticated (Author role or higher). The publish_posts capability is granted to Authors, Editors, and Administrators by default.
• Preconditions:
  • The target WordPress site must have Advanced Custom Fields (ACF) or Secure Custom Fields (SCF) installed and active.
  • Sensitive data must be stored in ACF fields attached to a post that the Author normally cannot access (e.g., a Private Post, a Draft, or a post belonging to another user).

3. Code Flow

1. Registration: ACFFieldBlocks\Rest::register_routes() registers the endpoint:

   register_rest_route(
       'acf-field-blocks/v1',
       '/values',
       array(
           'methods'             => \WP_REST_Server::READABLE,
           'callback'            => array( $this, 'get_all_values' ),
           'permission_callback' => function() {
               return current_user_can('publish_posts');
           }
       )
   );
   

2. Access: An Author-level user accesses the endpoint via a GET request with an id parameter.
3. Execution (Inferred from Patch): The get_all_values($request) method retrieves the id via $request->get_param('id').
4. Sink: It calls get_field_objects($id) (an ACF function). This function retrieves all fields for the given ID. Because the plugin does not check if the user can edit_post or read_post for that specific $id, the data is returned in the REST response.

4. Nonce Acquisition Strategy

To interact with the WordPress REST API using cookie-based authentication, a _wpnonce or X-WP-Nonce header is required. This nonce is tied to the wp_rest action.

1. Shortcode Identification: The plugin uses the [acf_field_block] or "ACF Field" block.
2. Setup: Create a test page containing the block.
3. Browser Execution:
   • Log in to the WordPress dashboard as the Author user.
   • Navigate to wp-admin/index.php.
   • Use browser_eval to extract the REST nonce usually available in the wpApiSettings object or via a specific call.
   • JS Script: window.wpApiSettings ? window.wpApiSettings.nonce : "".
   • Alternatively, fetch wp-admin/admin-ajax.php?action=rest-nonce to get a fresh nonce for the wp_rest action.

5. Exploitation Strategy

The goal is to use an Author account to read ACF field values from a Private Post created by an Administrator.

Step-by-Step Plan:

1. Target Identification: Determine the ID of a Private Post containing sensitive ACF data (e.g., Post ID 123).
2. Login: Authenticate as the Author user.
3. Nonce Retrieval: Obtain the wp_rest nonce.
4. Data Extraction: Send a GET request to the vulnerable endpoint.

HTTP Request (via http_request tool):

• Method: GET
• URL: http://<TARGET_URL>/wp-json/acf-field-blocks/v1/values?id=123
• Headers:
  • X-WP-Nonce: <NONCE_VALUE>
  • Content-Type: application/json
• Expected Response: A JSON object containing the label, name, and value of all ACF fields associated with Post 123.

6. Test Data Setup

1. Admin User Actions:
   • Create a new ACF Field Group (e.g., "Internal Secrets").
   • Add a Text field named api_key_secret.
   • Set the location to "Post Type is equal to Post".
   • Create a Private Post (ID $TARGET_ID).
   • Populate the api_key_secret field with a value: SUPER_SECRET_TOKEN_2026.
2. Attacker User Action:
   • Create a user with the Author role.

7. Expected Results

• The request should return a 200 OK status code.
• The JSON body should contain the data from the Private Post:

  {
    "api_key_secret": {
      "key": "field_xxxxxxxx",
      "label": "API Key Secret",
      "name": "api_key_secret",
      "type": "text",
      "value": "SUPER_SECRET_TOKEN_2026",
      ...
    }
  }
  

• If the vulnerability is patched, the endpoint should return a 403 Forbidden or restricted data.

8. Verification Steps

1. Manual Check: Verify the returned value matches the one set by the Admin in the Private Post.
2. WP-CLI Comparison:

   # Confirm the post is indeed private and not accessible by Author normally
   wp post get <TARGET_ID> --user=author_user_login
   # This should fail or return "Invalid post ID" if standard permissions are working.
   

9. Alternative Approaches

• Brute Forcing IDs: If the specific target ID is unknown, the agent can iterate through common IDs (1 to 100) to find hidden ACF metadata.
• Other Object Types: Test id values for other ACF-supported objects, such as user_1 (to read metadata of the Admin user) or term_5 (taxonomy metadata), as get_field_objects() accepts these string-based ID formats.