WCFM Frontend Manager for WooCommerce is the dashboard lots of multi-vendor marketplaces sit on top of. It gives each vendor a front-end area to manage their own products, orders and content without ever touching wp-admin. Versions up to and including 6.7.25 had a set of matching authorisation bugs in that dashboard that let any logged-in vendor reach well beyond their own shop. CVE-2026-4896 covers the lot.
Failing to check content ownership
The issue is a classic Insecure Direct Object Reference, repeated across three AJAX handlers in core/class-wcfm-ajax.php and core/class-wcfm-article.php. Each handler checks a nonce, confirms the caller has some kind of vendor capability, then trusts whatever object ID arrives in $_POST. The code doesn’t check to see if the caller actually owns the order they’re about to modify.
Here is the order status handler, trimmed for clarity:
public function wcfm_modify_order_status() {
if ( ! check_ajax_referer( 'wcfm_ajax_nonce', 'wcfm_ajax_nonce', false ) ) {
// abort
}
if (
! current_user_can( 'manage_woocommerce' ) &&
! current_user_can( 'wcfm_vendor' ) &&
! current_user_can( 'seller' ) &&
! current_user_can( 'vendor' ) &&
! current_user_can( 'shop_staff' )
) {
// abort
}
// Get the POSTed order id
$order_id = absint( $_POST['order_id'] );
// Get the new order status the user is trying to set, for the specified order id
$order_status = wc_clean( $_POST['order_status'] );
if ( wc_is_order_status( $order_status ) && $order_id ) {
$order = wc_get_order( $order_id );
$order->update_status( str_replace( 'wc-', '', $order_status ), '', true );
}
}
No ownership check. All it needs is a valid order id, a valid order status and to be logged-in as a seller/vendor. Any vendor can post any order ID to the site and drive it into any valid status: completed, cancelled, refunded, on-hold, failed. That can trigger payouts, fulfilment, or silently void orders that belong to somebody else.
The same pattern shows up in delete_wcfm_product() and delete_wcfm_article().
The product handler has a particularly nasty twist: for appointment-type products it calls remove_all_actions( 'before_delete_post' ), which strips any security or ownership hooks other plugins were relying on for that request. The plugin does actually have a helper function, wcfm_vendor_has_order(), but it’s not called from the vulnerable handler.
For products and articles, a simple comparison between post_author and get_current_user_id() would’ve closed this hole.
Check if your site is affected
If you’re running WCFM Frontend Manager for WooCommerce, verify the version you’re running:
# List the version of wc-frontend-manager installed wp plugin list --name=wc-frontend-manager --fields=name,version,status
Anything up to and including 6.7.25 is vulnerable.
If you suspect the issue has already been exploited, a couple of signals are worth checking. Order notes of the form “Order status updated to STATUS by USER” where the shop name does not match the vendor tied to the order line items are a strong indicator. So are trashed/binned posts whose post_author does not belong to a vendor who should have edit rights to the order.
What to do
The fix landed in 6.7.26 with a changelog line that just reads “Security fix – vendor authorisation”.
If you can’t update immediately, the practical interim step is to lock down vendor accounts: audit recent vendor sign-ups, disable any that look suspicious, and keep an eye on the WooCommerce order notes feed for status changes you did not authorise.
For anyone running a multi-vendor marketplace, this is also a good prompt to audit the other front-end dashboards on your stack. The WCFM bugs are a reminder that a role check on the way in is not the same thing as an ownership check on the way out.