ANALYSIS · ada45eb9· FINISHED 2026-06-13 · PATCHDIFF

ai-engine3.4.9 → 3.5.0✓ COMPLETED

Files8

Vulnerable2

True positives0

CVE matched2

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

CVE-2026-8719

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 8 CVE 2 Vuln 2

SORT

2 files · page 1/1

labs/mcp-oauth.php

AI: 1 vulnerabilities

CWE-269: Improper Privilege Management CVE-2026-8719

#%!d(float64=007)

labs/mcp.php

AI: 1 vulnerabilities

CWE-269: Improper Privilege Management CVE-2026-8719

#%!d(float64=008)

1–2 of 2

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2026-8719

Security writeup for CVE-2026-8719

✓ 2 FILES

## The Exploit

An authenticated user with Subscriber role (the lowest privilege tier in WordPress) can obtain and use an OAuth token to invoke admin-level MCP tools without holding administrator capabilities.

```http
POST /wp-json/mwai/v1/mcp/authorize HTTP/1.1
Host: vulnerable-site.local
Content-Type: application/x-www-form-urlencoded
Cookie: wordpress_logged_in_..=subscriber_session_cookie

client_id=malicious-mcp-client&response_type=code&redirect_uri=http://attacker.local/callback&scope=admin&_mwai_nonce=<valid_nonce>
```

The Subscriber user receives a consent page and can mint an OAuth token. Once obtained, that token grants access to admin-level MCP operations (such as `wp_create_user` or file operations) that the Subscriber could never invoke directly in WordPress. The attacker observes HTTP 200 with a valid authorization code, exchanges it for a bearer token, and subsequently calls MCP endpoints with that token in the Authorization header. Each call executes with the privileges of the token-holder, not the Subscriber's actual WordPress role.

## What the Patch Did

**Before**

```php
if ( $this->oauth ) {
  $token_data = $this->oauth->validate_token( $token );
  if ( $token_data ) {
    // Set current user based on OAuth token
    wp_set_current_user( $token_data['user_id'] );
    $auth_result = 'oauth';
```

**After**

```php
if ( $this->oauth ) {
  $token_data = $this->oauth->validate_token( $token );
  if ( $token_data ) {
    if ( !$this->oauth->user_can_authorize( $token_data['user_id'] ) ) {
      if ( $this->logging ) {
        error_log( '[AI Engine MCP] ❌ OAuth token rejected: user ' . $token_data['user_id'] . ' is not an administrator.' );
      }
      return false;
    }
    wp_set_current_user( $token_data['user_id'] );
    $auth_result = 'oauth';
```

The patch added a runtime capability gate: the `user_can_authorize()` method. This method is called every time an OAuth token is validated, ensuring the linked user currently holds administrator capabilities. If the check fails, the token is rejected and an error is logged. Additionally, the OAuth consent and token-submission endpoints now call `user_can_authorize()` at authorization time, preventing non-administrators from minting tokens in the first place:

```php
if ( !$this->user_can_authorize( $user->ID ) ) {
  if ( $this->logging ) {
    error_log( '[AI Engine MCP OAuth] ❌ Non-admin user ' . $user->ID . ' tried to authorize client ' . $params['client_id'] );
  }
  $this->render_error_page( 'Only administrators can authorize MCP applications on this site.' );
  exit;
}
```

## Root Cause

**CWE-269: Improper Access Control** (Broken Authorization). The vulnerability is a missing privilege check at the OAuth token consumption boundary. When a user presents a valid OAuth token (validated via signature or database lookup), the old code accepted it and set the current user based on `$token_data['user_id']` without verifying that this user retained administrator privileges at the moment of use. The token itself was not scope-limited or capability-bound; it granted access to all MCP tools unconditionally. Since MCP tools are designed for admin-level operations (user creation, file manipulation, etc.), any user who could obtain a token could escalate to the capabilities implied by the MCP layer. The authorization endpoint (`labs/mcp-oauth.php` lines 386–395) was also missing a capability check, allowing non-admin users to reach the consent flow and mint tokens.

## Why It Works

The load-bearing line is `if ( !$this->oauth->user_can_authorize( $token_data['user_id'] ) )` in the token validation path. Without this check, a Subscriber's token would pass through and `wp_set_current_user()` would make all downstream code see the Subscriber as the current user — but the MCP layer would treat that user as if they held admin privileges (because it was checking the token, not the user's actual role). The engineer added two additional defenses: the same check at token-minting time (authorization endpoint) and the same check at token-submission time (token endpoint). Together, these block non-admins from ever obtaining a token and reject any pre-existing tokens from downgraded users. The logging in all three locations provides forensic visibility. Without the runtime check in the token validation path, a token minted before a user was demoted from Admin to Subscriber would still grant admin MCP access — a token-refresh or privilege-revocation scenario. Without the authorization-time checks, an attacker who discovers they can reach the OAuth endpoints would immediately mint a token. The patch applies the gate at every trust boundary.

## Hardening Checklist

- **Apply capability gates at every auth boundary.** Do not assume that validating a credential (token, session cookie, API key) is sufficient; verify the user's current permissions at the moment the credential is used via `current_user_can( 'manage_options' )` or similar role-based checks. Tokens and sessions persist; roles and permissions do not.

- **Scope OAuth tokens to explicit capabilities at mint time.** Do not design tokens to inherit all capabilities of the user who minted them. Implement a `scope` parameter in the authorization request and store granted scopes in the token payload. Verify scope at the tool invocation boundary, not user role.

- **Gate privileged OAuth endpoints.** Treat the authorization endpoint, token endpoint, and scope-approval UI as privileged actions. Wrap these with `wp_verify_nonce()` and `current_user_can( 'manage_options' )` before rendering consent or issuing tokens.

- **Log all auth failures and scope mismatches.** Use `error_log()` with a machine-parseable format (e.g., `[AI Engine MCP] ❌ ...`) to record rejected tokens, failed capability checks, and unauthorized scope requests. Parse these logs weekly to detect token abuse.

- **Implement per-endpoint capability checks, not layer-wide role assumptions.** Each MCP tool endpoint should call `current_user_can()` with a tool-specific capability (e.g., `mcp_create_user`, `mcp_read_file`) rather than assuming all authenticated users holding a token can invoke all tools.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2026-8719

CVE CVE-2026-8719

PRODUCT ai-engine

AFFECTED ≤ 3.4.9

FIXED IN 3.5.0

STATUS Generated

Security writeup · CVE-2026-8719

Source files · 2

labs/mcp-oauth.php Linked

labs/mcp.php Linked

↗ NVD