GHSA-w8xc-8g92-v77h: Easy!Appointments appointments/store and appointments/update allow cross-provider appointment injection — Authorization Bypass

Summary Easy!Appointments correctly filters provider-scoped appointments in the appointments/search response, proving that provider isolation is an intended security boundary. However, the direct mutation endpoints appointments/store and appointments/update only check generic appointment privileges and never verify that the submitted id_users_provider belongs to the current session. A normal authenticated provider can inject new appointments into another provider's schedule via store, or reassign existing appointments into a foreign provider's calendar via update. The store path contains an additional write-before-crash bug: the unauthorized row is committed to the database before the controller crashes on a type error, so the attacker receives an error response while the foreign appointment is already persisted. Root Cause — Step by Step Code Flow Step 1 — Search correctly enforces provider isolation The search endpoint filters out appointments belonging to other providers — proving provider isolation is an intended boundary: // Appointments.php if ($role_slug === DB_SLUG_PROVIDER) { foreach ($appointments as $index => $appointment) { if ((int) $appointment['id_users_provider'] !== (int) $user_id) { unset($appointments[$index]); } } } Step 2 — store() only checks generic add permission The store endpoint checks only whether the caller can add appointments in general — no provider ownership check: // Appointments.php line 74-152 if (cannot('add', PRIV_APPOINTMENTS)) { abort(403, 'Forbidden'); } $appointment = json_decode(request('appointment'), true); Step 3 — Attacker-controlled id_users_provider saved directly The controller whitelists and persists the appointment including the attacker-controlled provider ID: $this->appointments_model->only($appointment, $this->allowed_appointment_fields); $appointment_id = $this->appointments_model->save($appointment); No check is performed to verify id_users_provider matches the current session. Step 4 — Write-befor