Analysis Report · Folder Analysis cache/timetics_1.0.36 → cache/timetics_1.0.37 — CVE-2025-5919

I'll analyze this code diff for security vulnerabilities.

**Vulnerability Existed: yes**
TRUE POSITIVE

**Cross-Site Request Forgery (CSRF) - CWE-352 - core/bookings/api-booking.php Lines 98-109 and 1236-1260**

**Old Code:**
```php
'permission_callback' => function () {
    return true;
},
```

**Fixed Code:**
```php
'permission_callback' => [$this, 'get_item_permission_callback'],
'permission_callback' => [$this, 'update_item_permission_callback'],

public function update_item_permission_callback($request){
    $nonce = $request->get_header('X-WP-Nonce');
    if (wp_verify_nonce($nonce, 'wp_rest')) {
        return true;
    }
    return false;
}

public function get_item_permission_callback($request){
    $nonce = $request->get_header('X-WP-Nonce');
    if (wp_verify_nonce($nonce, 'wp_rest')) {
        return true;
    }
    return false;
}
```

**Explanation:**

The original code had a critical security vulnerability. The REST API endpoints for GET and UPDATE operations had permission callbacks that unconditionally returned `true`, allowing any unauthenticated or unauthorized user to access and modify booking data without proper authorization checks.

The fix implements proper CSRF protection by:
1. Extracting the WordPress nonce from the request header (`X-WP-Nonce`)
2. Validating the nonce using `wp_verify_nonce()` with the `wp_rest` action
3. Only returning `true` if the nonce is valid, denying access otherwise

This prevents CSRF attacks by ensuring that state-changing operations (EDITABLE methods) and sensitive data access (READABLE methods) require a valid WordPress REST API nonce token. Without this validation, attackers could craft malicious requests to manipulate booking data on behalf of authenticated users.

I'll analyze this code diff for security vulnerabilities.

```
Vulnerability Existed: yes
TRUE POSITIVE
Improper Access Control / Missing Authorization Check - CWE-639 - core/frontend/templates/meeting-list.php - Lines 6-9 (Old Code)
[Old Code]
$meetings = Appointment::all([
    'posts_per_page' => $limit
]);

[Fixed Code]
$args = [
    'posts_per_page' => $limit
];

if ( ! current_user_can( 'manage_options' ) ) {
    $args['visibility'] = 'enabled';
}

$meetings = Appointment::all($args);

Explanation:
The original code retrieved ALL appointments without any authorization checks or visibility filters. This allowed any user (including non-authenticated or low-privilege users) to access all appointments regardless of their permission level. The fix adds a capability check using `current_user_can('manage_options')` to filter the query results. Non-admin users now only see appointments with 'visibility' set to 'enabled', implementing proper access control. This prevents unauthorized disclosure of sensitive meeting/appointment information to users who should not have access to all appointments.
```