Analysis Report Folder Analysis cache/tutor_3.9.3 → cache/tutor_3.9.4 - CVE-2025-13934

# Security Analysis: classes/Course.php

## Vulnerability 1: Enrollment Bypass Prevention

Vulnerability Existed: yes
FALSE POSITIVE
**Broken Access Control - CWE-639** - classes/Course.php lines 2122-2124

**Old Code:**
```php
// No enrollment check existed before course completion
$can_complete = apply_filters( 'tutor_user_can_complete_course', true, $user_id, $course_id );
```

**Fixed Code:**
```php
if ( ! tutor_utils()->is_enrolled( $course_id, $user_id ) ) {
    die( esc_html__( 'User is not enrolled in course', 'tutor' ) );
}

$can_complete = apply_filters( 'tutor_user_can_complete_course', true, $user_id, $course_id );
```

**Explanation:**
A critical access control vulnerability existed where unauthenticated or non-enrolled users could mark a course as complete without actually being enrolled. The fix adds an enrollment verification check that terminates execution if the user is not enrolled in the course, preventing unauthorized course completion.

---

## Vulnerability 2: Paid Course Enrollment Bypass

Vulnerability Existed: yes
TRUE POSITIVE
**Broken Access Control / Improper Authorization - CWE-639** - classes/Course.php lines 3010-3020

**Old Code:**
```php
if ( $password_protected ) {
    wp_send_json_error( __( 'This course is password protected', 'tutor' ) );
}
// Directly enrolls user without checking if course is paid or user purchased it
$enroll = tutor_utils()->do_enroll( $course_id, 0, $user_id );
```

**Fixed Code:**
```php
if ( $password_protected ) {
    wp_send_json_error( __( 'This course is password protected', 'tutor' ) );
}

if ( tutor_utils()->is_course_purchasable( $course_id ) ) {
    $is_enrolled = (bool) tutor_utils()->is_enrolled( $course_id, $user_id );
    
    if ( ! $is_enrolled ) {
        wp_send_json_error( __( 'Please purchase the course before enrolling', 'tutor' ) );
    }
}

$enroll = tutor_utils()->do_enroll( $course_id, 0, $user_id );
```

**Explanation:**
A significant authorization bypass vulnerability existed in the AJAX enrollment endpoint. Users could enroll in paid courses without purchasing them by directly calling the enrollment function. The fix adds a check to verify that if a course is purchasable (paid), the user must already be enrolled (which occurs automatically upon purchase). This prevents unauthorized enrollment in premium courses.

```
Vulnerability Existed: yes
TRUE POSITIVE
Broken Access Control - CWE-639 - classes/Quiz.php Lines 286-289

Old Code:
$attempt_details = self::attempt_details( Input::post( 'attempt_id', 0, Input::TYPE_INT ) );
$feedback        = Input::post( 'feedback', '', Input::TYPE_KSES_POST );
$attempt_info    = isset( $attempt_details->attempt_info ) ? $attempt_details->attempt_info : false;
if ( $attempt_info ) {

Fixed Code:
$attempt_details = self::attempt_details( Input::post( 'attempt_id', 0, Input::TYPE_INT ) );
$feedback        = Input::post( 'feedback', '', Input::TYPE_KSES_POST );
$attempt_info    = isset( $attempt_details->attempt_info ) ? $attempt_details->attempt_info : false;
$course_id       = tutor_utils()->avalue_dot( 'course_id', $attempt_info, 0 );

if ( ! tutor_utils()->is_instructor_of_this_course( get_current_user_id(), $course_id ) ) {
	wp_send_json_error( tutor_utils()->error_message() );
}

if ( $attempt_info ) {

Explanation:
The original code was missing authorization checks before processing quiz feedback. Any authenticated user could submit feedback on any quiz attempt by directly posting an attempt_id, regardless of whether they were the instructor of the course containing that quiz. The fix adds a critical access control check that verifies the current user is an instructor of the course before allowing feedback submission. This prevents privilege escalation and unauthorized modification of quiz attempt data.
```

```
Vulnerability Existed: no
Authorization Bypass Prevention - CWE-639 - ecommerce/CouponController.php [580-583, 630-633]

Old Code:
if ( ! current_user_can( 'manage_options' ) ) {
    tutor_utils()->error_message();
}

Fixed Code:
tutor_utils()->check_current_user_capability();

Explanation:
The old code had a critical authorization vulnerability. When a user lacked the 'manage_options' capability, the code would call tutor_utils()->error_message() but would NOT exit/return, allowing execution to continue to the sensitive operations below (bulk actions and permanent deletion). This is a classic authorization bypass - the function would display an error message but then proceed to process coupon operations anyway.

The fix replaces this with tutor_utils()->check_current_user_capability(), which presumably performs proper capability checking AND terminates execution if the user lacks authorization (typical implementation pattern for such utility functions). This prevents the authorization bypass by ensuring that unprivileged users cannot execute bulk coupon actions or permanent deletions.

This fix addresses CWE-639 (Authorization Bypass Through User-Controlled Key) by properly enforcing authorization checks before allowing sensitive operations.
```

Let me analyze the diff you provided:

**Vulnerability 1:**

    Vulnerability Existed: yes
FALSE POSITIVE
    Cross-Site Request Forgery (CSRF) - CWE-352 - ecommerce/OrderController.php lines 261-262
    Old Code:
    if ( ! tutor_utils()->is_nonce_verified() ) {
        $this->json_response( tutor_utils()->error_message( 'nonce' ), null, HttpHelper::STATUS_BAD_REQUEST );
    }
    Fixed Code:
    tutor_utils()->check_nonce();
    tutor_utils()->check_current_user_capability();
    Explanation:
    The original code had a CSRF vulnerability. The old implementation used `is_nonce_verified()` which only checks if the nonce is valid but does not terminate execution on failure - it relies on the conditional to return early. However, the fixed code calls `check_nonce()` which should perform the nonce validation and halt execution if verification fails, preventing CSRF attacks. Additionally, the fix adds an explicit capability check via `check_current_user_capability()` which provides defense-in-depth by ensuring the user has appropriate permissions to access this AJAX endpoint. The rename from `get_order_by_id()` to `ajax_get_order_details()` also improves clarity that this is an AJAX handler.

**Vulnerability 2:**

    Vulnerability Existed: yes
TRUE POSITIVE
    Missing Authorization Check - CWE-862 - ecommerce/OrderController.php lines 261-262
    Old Code:
    if ( ! tutor_utils()->is_nonce_verified() ) {
        $this->json_response( tutor_utils()->error_message( 'nonce' ), null, HttpHelper::STATUS_BAD_REQUEST );
    }
    Fixed Code:
    tutor_utils()->check_nonce();
    tutor_utils()->check_current_user_capability();
    Explanation:
    The original code only verified the nonce but did not check user capabilities/permissions. The fixed code explicitly adds `tutor_utils()->check_current_user_capability()` which performs authorization checks. This prevents unauthorized users from accessing order details they shouldn't have access to, addressing a missing authorization vulnerability (CWE-862).

Vulnerability Existed: yes
TRUE POSITIVE
SQL Injection - CWE-89 - models/CouponModel.php - Line 813

Old Code:
```php
'coupon_code'   => $coupon_code,
```

Fixed Code:
```php
'coupon_code'   => esc_sql( $coupon_code ),
```

Explanation:
The `$coupon_code` variable is passed directly to the `get_coupon()` method without sanitization. This creates an SQL injection vulnerability if the coupon code parameter comes from user input (via GET, POST, or other external sources). An attacker could inject malicious SQL code through the coupon code parameter. The fix applies `esc_sql()`, a WordPress function that escapes SQL special characters, preventing SQL injection attacks by properly escaping the user-supplied input before it's used in a database query.

I'll analyze the provided code diff for security vulnerabilities.

**Analysis Results:**

Vulnerability Existed: no

No security vulnerabilities identified in this diff.

**Explanation:**

This diff only contains version number updates in the plugin header and constant definition:
- Line 7: Plugin version header changed from '3.9.3' to '3.9.4'
- Line 29: TUTOR_VERSION constant changed from '3.9.3' to '3.9.4'

These are routine version bumps with no changes to executable code, input validation, data handling, authentication mechanisms, or any other security-relevant functionality. Version string updates alone do not introduce or fix security vulnerabilities.

Vulnerability Existed: no

No Vulnerabilities Detected - [N/A] - [vendor/composer/installed.php] [Lines 6, 16]

Old Code:
```
'reference' => 'a5dd7291aa5fa582e64a050945b7ec437a833cc5',
```

Fixed Code:
```
'reference' => '043bcc9b76cd1e56219d167b8be313b5aa933109',
```

Explanation:
This diff shows a version reference update in the Composer lock file, changing the git commit reference from `a5dd7291aa5fa582e64a050945b7ec437a833cc5` to `043bcc9b76cd1e56219d167b8be313b5aa933109`. This is a routine dependency version update (from Tutor 3.9.3 to 3.9.4) and does not introduce or fix any security vulnerabilities. The change is merely metadata that tracks which commit of the themeum/tutor package is installed. No code logic, access controls, input validation, or security-related functionality is modified in this diff.

Vulnerability Existed: yes
FALSE POSITIVE
Improper Input Validation - CWE-20 / Insufficient Access Control - CWE-284 - views/pages/ecommerce/order-list.php - Line 30

Old Code:
```php
$order_controller = new OrderController();
```

Fixed Code:
```php
$order_controller = new OrderController( false );
```

Explanation:
The vulnerability existed in the original code. The `OrderController` is being instantiated without any access control parameter. The fix passes `false` as an argument to the constructor, which likely disables or restricts some privileged functionality (possibly admin-only operations or unrestricted data access). Without examining the `OrderController` class definition, the most probable vulnerability is that the controller was performing operations without proper authorization checks when instantiated without parameters. The `false` parameter likely forces the controller into a restricted mode that validates user permissions before allowing sensitive operations. This is consistent with CWE-284 (Improper Access Control) where sensitive functionality was accessible without proper authorization enforcement. The fix implements access control by passing a parameter that triggers permission validation within the controller.

```
Vulnerability Existed: yes
TRUE POSITIVE
Missing Authorization Check - CWE-639 - views/pages/view_attempt.php [Lines 21-32]

Old Code:
$attempt_data = $attempt;
$user_id      = tutor_utils()->avalue_dot( 'user_id', $attempt_data );
$quiz_id      = $attempt && isset( $attempt->quiz_id ) ? $attempt->quiz_id : 0;
if ( ! $attempt ) {
	tutor_utils()->tutor_empty_state( __( 'Attemp not found', 'tutor' ) );
	return;
}
if ( 0 === $quiz_id ) {
	tutor_utils()->tutor_empty_state( __( 'Attemp not found', 'tutor' ) );
	return;
}

Fixed Code:
$attempt_data = $attempt;
$user_id      = tutor_utils()->avalue_dot( 'user_id', $attempt_data );
$quiz_id      = $attempt && isset( $attempt->quiz_id ) ? $attempt->quiz_id : 0;
$course_id    = tutor_utils()->avalue_dot( 'course_id', $attempt_data );
if ( ! $attempt ) {
	tutor_utils()->tutor_empty_state( __( 'Attempt not found', 'tutor' ) );
	return;
}
if ( 0 === $quiz_id ) {
	tutor_utils()->tutor_empty_state( __( 'Attempt not found', 'tutor' ) );
	return;
}

if ( ! tutor_utils()->is_instructor_of_this_course( get_current_user_id(), $course_id ) ) {
	tutor_utils()->tutor_empty_state();
	return;
}

Explanation:
The original code was missing an authorization check. The page loaded attempt data and allowed processing without verifying that the current user is an instructor of the course associated with the attempt. This could allow unauthorized users (such as other instructors or students) to access attempt details they shouldn't have access to. The fix adds an explicit authorization check using `is_instructor_of_this_course()` to verify the current user is an instructor of the course before proceeding, preventing unauthorized access to quiz attempt data.
```