Most recent entries from all

EUVD-2026-342439

fkie_cve-2026-52839

Easy!Appointments is a self hosted appointment scheduler. Versions prior to 1.6.0 correctly filter 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. Version 1.6.0 patches the issue.

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

Affected: Packagist: alextselegidis/easyappointments

## 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: ```php // 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…