ANALYSIS · c1853489 · PATCHDIFF

Folder Analysistutor_3.9.3 → tutor_3.9.4✓ COMPLETED

Started2026-09-05 00:23:40Z Finished2026-09-05 00:24:07Z Elapsed26s

Vulnerabilities 7

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

CVE-2025-13679

FILTERS 0

STATUS

JUDGE

CVE MATCH

EXTENSION · 1

CWE · 0

OPTIONS

Hide “No vulnerability” Hide unjudged

1/8

All 8 CVE 1 Vuln files 6

SORT

ecommerce/OrderController.php

AI: 1 vulnerabilities

FUNCTIONS · SOURCE GONE CVE-2025-13679 1 TP

#004

1–1 of 1

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2025-13679

Security writeup for CVE-2025-13679

✓ 1 FILE

## The Exploit

An authenticated subscriber can directly query the AJAX endpoint `wp-admin/admin-ajax.php?action=tutor_order_details` with an arbitrary order ID and receive a JSON response containing full order details — including student name, email, phone number, and billing address — without any role-based permission check.

```http
POST /wp-admin/admin-ajax.php HTTP/1.1
Host: target.wordpress.local
Content-Type: application/x-www-form-urlencoded
Cookie: wordpress_logged_in=subscriber_session_token

action=tutor_order_details&order_id=1&_wpnonce=valid_nonce_for_subscriber
```

**Authentication required:** Subscriber-level WordPress user (the lowest standard authenticated role).

When this request lands, the server returns a 200 response containing the order object in JSON — including `student_name`, `student_email`, `phone_number`, and `billing_address` fields. An attacker iterates the `order_id` parameter starting from 1 and exfiltrates all order records in the system without administrative privileges.

## What the Patch Did

**Before:**
```php
add_action( 'wp_ajax_tutor_order_details', array( $this, 'get_order_by_id' ) );

public function get_order_by_id() {
    if ( ! tutor_utils()->is_nonce_verified() ) {
        $this->json_response( tutor_utils()->error_message( 'nonce' ), null, HttpHelper::STATUS_BAD_REQUEST );
    }
    // ... proceeds directly to fetch and return order data
}
```

**After:**
```php
add_action( 'wp_ajax_tutor_order_details', array( $this, 'ajax_get_order_details' ) );

public function ajax_get_order_details() {
    tutor_utils()->check_nonce();
    tutor_utils()->check_current_user_capability();
    // ... proceeds to fetch and return order data
}
```

The patch added a capability check via `tutor_utils()->check_current_user_capability()`. This method (based on standard WordPress patterns) verifies that the current user possesses sufficient capabilities — typically `manage_options` or a custom shop/instructor capability — before allowing access to order details. The nonce verification remains as a CSRF shield, but is now joined by a capability gate that enforces role-based access control.

## Root Cause

**CWE-862: Missing Authorization** — The `get_order_by_id()` AJAX handler verified request authenticity (via nonce) but failed to enforce authorization (via capability check). The attacker-controlled `order_id` parameter in `$_POST` or `$_GET` flows directly into a database query without validating whether the subscriber making the request is permitted to view that order. The trust boundary crossed was between "user is logged in" and "user is allowed to view this resource" — the former was checked, the latter was not. On a multi-tenant or multi-vendor store, a malicious subscriber on one account could enumerate and extract PII from orders belonging to other accounts.

## Why It Works

The load-bearing line is `tutor_utils()->check_current_user_capability()`. Remove it, and the bug persists — a nonce alone proves the request came from an authenticated session, not that the session holder *should* access the requested order. The nonce check prevents CSRF (a different threat) but has no concept of "does this user own this order" or "does this user have admin rights." The capability check is the only control that answers the authorization question. The developer likely added both checks in sequence to maintain defense-in-depth: nonce guards against cross-site request forgery on an admin's browser; capability guards against a subscriber escalating their access to read any order in the database.

## Hardening Checklist

- **Audit all AJAX handlers (`add_action('wp_ajax_*')`) in your plugin.** For each, verify it calls either `current_user_can('capability_name')` or a wrapper method that does, *before* accessing sensitive data. Do not assume nonce verification grants permission.
- **Implement capability checks at the function entry point.** In WordPress, call `current_user_can()` immediately after nonce verification; do not defer the check to a helper or allow the function to proceed if the capability fails.
- **For multi-user resource access (orders, user profiles, posts), bind the query to the current user.** Use `wp_get_current_user()` and filter queries by `post_author`, `customer_id`, or equivalent field, so even a capability check only returns that user's records.
- **Write integration tests that verify subscribers and contributors cannot access admin-only AJAX endpoints.** Simulate authenticated requests from low-privilege roles and assert a 403 or error response, not data exfiltration.
- **Review custom capabilities assigned to subscriber and above.** If you create custom caps like `read_orders`, bind them tightly to the roles that truly need them (typically Instructor or Shop Manager, not Subscriber).

## References

- https://nvd.nist.gov/vuln/detail/CVE-2025-13679

CVE CVE-2025-13679

PRODUCT Folder Analysis

AFFECTED ≤ tutor_3.9.3

FIXED IN tutor_3.9.4

STATUS Generated

Security writeup · CVE-2025-13679

Source files · 1

ecommerce/OrderController.php Linked

↗ NVD