WCFM Frontend Manager for WooCommerce CVE-2026-4896: Brief Summary of an IDOR Vulnerability Enabling Cross Vendor Data Manipulation

Introduction

A missing ownership check in one of WordPress's most popular multivendor marketplace plugins means that any registered vendor can modify orders, delete products, and trash pages belonging to other vendors or even the store administrator. For the 20,000+ WooCommerce marketplaces that rely on WCFM Frontend Manager to run their vendor dashboards, this directly threatens data integrity and business continuity.

WCFM Frontend Manager, developed by WC Lovers, is a widely used plugin that turns a standard WooCommerce store into a full multivendor marketplace, with vendor dashboards for managing products, orders, bookings, and subscriptions. It competes with Dokan and WC Vendors, and its 20,000+ active installations are a significant share of the WordPress multivendor ecosystem.

Technical Information

CVE-2026-4896 is classified under CWE-639: Authorization Bypass Through User-Controlled Key. The root cause is simple. Several AJAX handlers in the plugin accept user-supplied object IDs (order IDs, product IDs, article IDs) and act on them after checking only two things: that the request includes a valid nonce, and that the user holds a vendor-level role. None of these handlers checks whether the resource being modified or deleted belongs to the vendor making the request.

Affected Endpoints

The following AJAX actions are vulnerable:

The article management controller (class-wcfm-article.php) is also affected and allows unauthorized article editing.

Order Status Manipulation

The wcfm_modify_order_status function reads order_id and order_status from the POST request. After verifying the wcfm_ajax_nonce and checking whether the user holds roles such as wcfm_vendor or manage_woocommerce, the code instantiates the order object directly with wc_get_order( $order_id ) and calls $order->update_status(). Nothing confirms that the vendor is associated with the order, so Vendor A can change the status of an order that belongs to Vendor B, or even one the store administrator manages directly.

Arbitrary Content Deletion

The delete_wcfm_article and delete_wcfm_product functions accept articleid and proid parameters respectively. Once the nonce and role checks pass, the functions run wp_delete_post() or wp_trash_post() on whatever IDs were supplied. Because WordPress post IDs are sequential integers, a malicious vendor could iterate through them and delete products belonging to the marketplace owner or to competing vendors. The article management controller in class-wcfm-article.php follows the same pattern. It handles article editing with no ownership validation.

Attack Flow

1. An attacker registers as a vendor on a WCFM-powered marketplace (or compromises an existing vendor account).
2. The attacker authenticates and obtains a valid wcfm_ajax_nonce from the vendor dashboard.
3. The attacker crafts a POST request to the wcfm_modify_order_status AJAX action, supplying an arbitrary order_id (for example, an order belonging to a competing vendor) and a desired order_status.
4. The server validates the nonce and confirms the user has a vendor role, then processes the status change without verifying ownership.
5. The attacker repeats this for delete_wcfm_product or delete_wcfm_article, supplying sequential post IDs to trash or permanently delete products, articles, or even WordPress pages.

The attack requires no user interaction and can be fully automated once the attacker has vendor credentials and a valid nonce.

Patch Information

WCFM Frontend Manager version 6.7.26, released on March 16, 2026 (changeset 3483695 in the WordPress plugin repository), patches the vulnerability. The fix introduces ownership validation through the function wcfm_user_can_perform_request() across all affected code paths. The function checks whether the authenticated user is either an administrator or the actual author/owner of the target post or order. If the check fails, the handler ends the request immediately with an error.

Fix in delete_wcfm_product (class-wcfm-ajax.php)

In the vulnerable version, the function extracted the proid parameter and went straight to deleting the product. Version 6.7.26 adds a multi-step guard. First, it calls wc_get_product() to confirm the product exists. Then it reads the post_author with get_post_field('post_author', $product_id) and passes it through the new ownership gate:

$resource_owner_id = get_post_field('post_author', $product_id);
if (!wcfm_user_can_perform_request($resource_owner_id, 'product_delete')) {
    wp_send_json_error(esc_html__('You don\'t have permission to do this.', 'woocommerce'));
}

This blocks any vendor from deleting products that belong to another vendor or to the store admin.

Fix in wcfm_modify_order_status (class-wcfm-ajax.php)

Previously, a vendor could supply any order_id and change its status. The patched code validates the order object, then calls $WCFM->wcfm_vendor_support->wcfm_is_order_for_vendor($order_id) to confirm the order is associated with the current vendor:

$order = wc_get_order($order_id);
if (!is_a($order, 'WC_Order') || !$WCFM->wcfm_vendor_support->wcfm_is_order_for_vendor($order_id)) {
    wp_send_json_error(__('Invalid Order', 'wc-frontend-manager'));
}

The handler also validates the supplied status string with wc_is_order_status() before applying it.

Fix in delete_wcfm_article and the Article Management Controller (class-wcfm-article.php)

The article deletion handler gets the same treatment. After extracting the article ID, the patched code fetches the post object, confirms it is a post post type (not a page or product), and then checks the post_author against the current user:

$wcfm_article = get_post($articleid);
if (!$wcfm_article || $wcfm_article->post_type !== 'post') {
    wp_send_json_error(__('Invalid Article.', 'wc-frontend-manager'));
}

$resource_owner_id = $wcfm_article->post_author;
if (!wcfm_user_can_perform_request($resource_owner_id, 'article_delete')) {
    wp_send_json_error(esc_html__('You don\'t have permission to do this.', 'woocommerce'));
}

The wcfm-articles-manage AJAX controller, which handles article editing, gets the same check. It uses the context tag article_edit instead of article_delete, but the validation is identical and confirms that the requesting user is the author of the resource.

The fix is a textbook IDOR remediation. Every handler that acts on a user-supplied object ID now confirms the requesting user is the legitimate owner of that object before proceeding. The plugin author (wclovers) committed the patch, and updating to version 6.7.26 or later applies it.

Affected Systems and Versions

The vulnerability affects any WordPress installation running the WCFM Frontend Manager for WooCommerce plugin (slug: wc-frontend-manager) at version 6.7.25 or earlier. The plugin must be active, and the attacker needs at least Vendor-level authentication. Sites that use WCFM with the WooCommerce Bookings, Subscriptions, or Listings extensions are equally affected, because the vulnerable code lives in the core WCFM plugin.

Vendor Security History

WC Lovers has responded quickly to security issues, but WCFM keeps producing authorization-related vulnerabilities. Version 6.7.26, the same release that patches CVE-2026-4896, also fixes an Authenticated (Shop Manager+) Arbitrary Options Update vulnerability and a separate Broken Access Control vulnerability. Before that, version 6.7.25 fixed a Missing Authorization flaw tracked as CVE-2025-54004. These repeated access control gaps suggest that the plugin's complex role management system, which supports store admins, vendors, shop managers, and delivery personnel, has historically lacked a centralized authorization framework. Adding wcfm_user_can_perform_request() in version 6.7.26 appears to be a step toward closing that architectural gap. Given this history, marketplace administrators should treat WCFM updates as high priority.

References

• Wordfence Threat Intel: WCFM Frontend Manager <= 6.7.25 IDOR Vulnerability
• NVD: CVE-2026-4896 Detail
• CVE Record: CVE-2026-4896
• Vulnerable Source: class-wcfm-ajax.php (tag 6.7.24)
• Vulnerable Source: class-wcfm-article.php (tag 6.7.24)
• Patched Source: class-wcfm-ajax.php (tag 6.7.26)
• Patched Source: class-wcfm-article.php (tag 6.7.26)
• WordPress Plugin Page: WCFM Frontend Manager
• Wordfence: WCFM Frontend Manager <= 6.7.24 Missing Authorization (CVE-2025-54004)