Easy!Appointments appointments/store and appointments/update allow cross-provider appointment injection — Authorization Bypass

• <= 1.5.2

## 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 => $appointm

GitHub Advisory Database

• ECOSYSTEM: introduced 0; fixed 1.6.0

## 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 => $appointm

GitHub Advisory Database via OSV