BEAR – Bulk Editor and Products Manager Professional for WooCommerce by Pluginus.Net <= 1.1.5 - Cross-Site Request Forgery to Product Data Modification

This plan outlines the research and exploitation strategy for CVE-2026-1672, a Cross-Site Request Forgery (CSRF) vulnerability in the BEAR – Bulk Editor and Products Manager Professional for WooCommerce plugin.

---

1. Vulnerability Summary

The BEAR (Bulk Editor and Products Manager) plugin (formerly WOOBE) allows for mass editing of WooCommerce products. The vulnerability exists in the woobe_redraw_table_row() function (likely located in the main plugin class or an AJAX handler class). This function is hooked to the wp_ajax_woobe_redraw_table_row action.

The function fails to implement a nonce check (using check_ajax_referer or wp_verify_nonce). While the function is intended to simply return the HTML for a specific product row after an update, it appears to process or trust input parameters in a way that allows modification of product data (e.g., price, title, SKU) via CSRF if an attacker can trick an administrator into sending a crafted request.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: woobe_redraw_table_row
• Method: POST (standard for WordPress AJAX)
• Vulnerable Parameter(s): product_id, and parameters related to field values (likely passed via $_REQUEST).
• Authentication Level: Requires an active session of a user with shop_manager or administrator roles.
• Preconditions: The victim must be logged into the WordPress admin panel.

3. Code Flow (Inferred)

1. Registration: The plugin registers the AJAX hook:
   add_action('wp_ajax_woobe_redraw_table_row', array($this, 'woobe_redraw_table_row'));
2. Entry Point: An AJAX request is sent to admin-ajax.php with action=woobe_redraw_table_row.
3. Vulnerable Logic: Inside woobe_redraw_table_row():
   • The code retrieves product_id from $_REQUEST['product_id'].
   • The code retrieves field data. In some versions of this plugin, the "redraw" logic is used to commit changes to the database before returning the new HTML, or it calls an internal save method without verifying nonces.
   • The WC_Product object is instantiated and updated based on the provided request parameters.
4. Missing Check: The function lacks check_ajax_referer('woobe_nonce', 'nonce') or similar validation, allowing any cross-site request to trigger the execution.

4. Nonce Acquisition Strategy

According to the vulnerability description, the woobe_redraw_table_row function missing nonce validation. Therefore, no nonce should be required to successfully execute the state-changing operation.

If a nonce is present but the check is weak (e.g., uses -1 or is conditional), the agent should check the global JS variables in the admin dashboard:

1. Variable Name: woobe_vars or woobe_settings (common localization keys for this plugin).
2. Key: nonce or woobe_nonce.
3. Acquisition:
   • Navigate to the Products Bulk Editor page: /wp-admin/admin.php?page=woobe.
   • Run browser_eval("window.woobe_vars?.nonce").

5. Exploitation Strategy

The goal is to change a product's price via a CSRF-style POST request.

Step-by-Step Plan:

1. Identify Target Product: Get the ID of an existing WooCommerce product.
2. Craft Payload: The payload must target admin-ajax.php. Based on plugin structure, we need to identify the exact parameter name used for field updates. Common parameters in BEAR: field, value, product_id.
3. Execute Request: Use http_request to simulate the admin performing the action.

Example Payload (Draft):

• URL: http://localhost:8080/wp-admin/admin-ajax.php
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Body:

  action=woobe_redraw_table_row&product_id=[ID]&field=regular_price&value=0.01
  

  (Note: The exact parameter names for the "value" may be $_REQUEST['value'] or nested in an array. The agent should verify this by grep-ing the function body in the source code first.)

6. Test Data Setup

1. WooCommerce: Ensure WooCommerce is installed and configured.
2. Product: Create a product with a known price:

   wp eval "wc_create_product(array('name' => 'Test Product', 'regular_price' => '100'));"
   

3. Identify ID: Get the product ID using wp post list --post_type=product.
4. Plugin Setup: Ensure "BEAR Bulk Editor" is active.

7. Expected Results

• The server responds with a 200 OK and a chunk of HTML representing the updated table row.
• The product price in the database is changed to the value specified in the attack payload.

8. Verification Steps

After sending the http_request, verify the change using WP-CLI:

# Check the product price
wp post get [PRODUCT_ID] --field=post_id
wp eval "echo get_post_meta([PRODUCT_ID], '_regular_price', true);"

If the output is 0.01 (or your chosen value), the CSRF is successful.

9. Alternative Approaches

If woobe_redraw_table_row only renders data but doesn't save it, the vulnerability description implies that the act of calling the redraw might be coupled with a save operation or that there's a sibling function.

• Alternative 1: Search for woobe_save_product_data or woobe_update_page_field. If these also lack nonce checks, they are viable targets.
• Alternative 2: If the price is updated via a specific metadata field, the payload might look like: action=woobe_redraw_table_row&product_id=[ID]&field=title&value=HACKED.

10. Source Code Investigation (Grep Commands)

The agent should start by running these to confirm identifiers:

# Find the AJAX handler
grep -rn "wp_ajax_woobe_redraw_table_row" .

# Examine the function body for parameter names and missing nonce checks
grep -rn "function woobe_redraw_table_row" . -A 50

# Check for localized script data to find nonce variable names (if any)
grep -rn "wp_localize_script" . -A 10 | grep "nonce"