ANALYSIS · 3226078c· FINISHED 2026-06-13 · PATCHDIFF

multimanager-wp1.0.5 → 1.1.0✓ COMPLETED

Files2

Vulnerable1

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-11028

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 2 CVE 1 Vuln 1

SORT

1 files · page 1/1

includes/class-multi-manager-wp-rest-api.php

AI: 1 vulnerabilities

CWE-284: Improper Access Control CVE-2024-11028

#%!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-11028

Security writeup for CVE-2024-11028

✓ 1 FILE

## The Exploit

An unauthenticated attacker can invoke the REST API endpoint without authentication and request an impersonation link for any user, including administrators.

```http
GET /wp-json/multi-manager-wp/v1/users/impersonate?id=1 HTTP/1.1
Host: target.local
User-Agent: curl/7.68.0
Accept: */*
```

The endpoint returns a signed impersonation token or redirects directly to an authenticated session as the target user (typically user ID 1, the initial administrator). An attacker observes a 200 response containing session credentials or an immediate redirect to the WordPress dashboard logged in as the administrator. The attacker can now perform any action the impersonated user could perform, including modifying site settings, creating backdoor accounts, or exfiltrating data.

## What the Patch Did

**Before**
```php
register_rest_route( $namespace, '/' . $users . '/impersonate', array(
    array(
        'methods'             => WP_REST_Server::READABLE,
        'callback'            => array( $this, 'impersonate_user' ),
        'permission_callback' => array( $this, 'check_permissions' ),
        'args'                => array(
            'id' => array(
                'description' => __( 'The ID of the user to impersonate.' ),
                'type'        => 'integer',
                'required'    => true,
            ),
        ),
    ),
) );
```

**After**
```php
/*register_rest_route( $namespace, '/' . $users . '/impersonate', array(
    array(
        'methods'             => WP_REST_Server::READABLE,
        'callback'            => array( $this, 'impersonate_user' ),
        'permission_callback' => array( $this, 'check_permissions' ),
        'args'                => array(
            'id' => array(
                'description' => __( 'The ID of the user to impersonate.' ),
                'type'        => 'integer',
                'required'    => true,
            ),
        ),
    ),
) );*/
```

The patch entirely disables the REST route by commenting out the `register_rest_route()` call. This removes the entire endpoint from the WordPress REST API surface and prevents any request from reaching the `impersonate_user` callback, regardless of whether the `check_permissions` callback was robust. Rather than attempting to strengthen the permission check, the vendor chose complete feature removal, indicating the impersonation mechanism itself was considered too high-risk to maintain in production.

## Root Cause

**CWE-284: Improper Access Control.** The REST endpoint `/wp-json/multi-manager-wp/v1/users/impersonate` accepted a user-supplied integer parameter `id` in the query string without enforcing authentication or authorization prior to route registration. Although a `permission_callback` function (`check_permissions`) was specified in the route definition, the vulnerability likely stemmed from that callback failing to verify the current user's authentication state or capabilities. The attacker-controlled `id` parameter flows directly into the `impersonate_user` callback, which trusts it to specify which user session to create. The trust boundary crossed is the REST API entry point itself: unauthenticated requests should never reach a route that performs privilege escalation, yet the endpoint accepted them and processed the impersonation request.

## Why It Works

The load-bearing change is the removal of the `register_rest_route()` call entirely. If only the `permission_callback` had been strengthened—for instance, by adding a check like `current_user_can( 'manage_users' )`—the endpoint would remain registered and callable; an attacker might still discover it, attempt probing, or (in scenarios where the permission callback was misconfigured or had a logic bug) exploit it. By commenting out the route registration, WordPress never adds the endpoint to its routing table, so no HTTP request ever reaches the callback function at all. The permission callback becomes irrelevant because the route does not exist. The vendor's decision to disable rather than harden suggests they recognized that user impersonation, even when gated by a permission check, is fundamentally at odds with REST API best practices—sessions created outside normal authentication flows cannot be properly audited, and the feature is difficult to secure. The engineer added nothing else because nothing else was needed: the entire route registration block is the vulnerability, and its removal is the complete fix.

## Hardening Checklist

- **Require explicit authentication before route registration.** Use `'permission_callback' => function() { return is_user_logged_in(); }` at minimum, or apply `rest_ensure_logged_in()` helper to reject unauthenticated requests before any callback executes. Do not rely solely on `check_permissions` if route registration itself is unconditional.

- **Audit `check_permissions` callback implementation.** If the callback exists, examine its source code in the context of this vulnerability. Confirm it calls `current_user_can()` with the appropriate capability (e.g., `manage_users`) and does not fall through to a default `true` or `return` with no value.

- **Disable high-risk features by default.** User impersonation, session hijacking, or privilege-escalation utilities should be opt-in and off by default. Wrap `register_rest_route()` in a conditional: `if ( apply_filters( 'enable_impersonate_endpoint', false ) ) { ... }` to allow advanced users to enable it only in trusted environments.

- **Implement nonce validation on state-changing routes.** Even if impersonation were re-enabled, add a `wp_verify_nonce()` check inside the callback to ensure the request originated from a form or admin page, not a cross-site attack vector: `wp_verify_nonce( $_REQUEST['_wpnonce'], 'impersonate_user' )`.

- **Log and rate-limit impersonation attempts.** If the feature must exist, record every impersonation event (timestamp, impersonator, impersonated user, source IP) to an audit table and implement rate limiting via `wp_cache_get()` and `wp_cache_set()` to block repeated failed or suspicious requests from a single IP.

## References

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

CVE CVE-2024-11028

PRODUCT multimanager-wp

AFFECTED ≤ 1.0.5

FIXED IN 1.1.0

STATUS Generated

Security writeup · CVE-2024-11028

Source files · 1

includes/class-multi-manager-wp-rest-api.php Linked

↗ NVD