Easy!Appointments CVE-2026-52841

The attacker must hold an active authenticated session as any backend user role - admin, provider, or secretary - in the target Easy!Appointments installation; anonymous access is insufficient. The target installation must have the Google Calendar synchronization feature enabled and configured, since the vulnerable code path is only reachable when Google sync is active. The attacker supplies a different user's numeric provider_id as a URL parameter to the OAuth initiation endpoint, then completes the Google OAuth consent flow using their own Google account. Exploitation is bounded by: (1) a requirement for a valid backend account (PR:L at minimum), (2) the need to know or enumerate the victim's numeric provider_id (likely low-entropy sequential integers), and (3) a deployment where Google Calendar sync is enabled. No elevated privileges such as admin rights are required - the flaw is exploitable by the lowest-privilege backend roles. No network positioning or man-in-the-middle capability is needed.

The official CVSS 3.1 score of 3.1 (Low) with vector AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:N understates realistic exploitation difficulty in one direction and overstates it in another. The PR:H (High Privileges) assignment conflicts directly with the CVE description, which names secretary and provider roles as viable attackers - these are authenticated but low-privilege backend roles, making PR:L more accurate. The UI:R assignment is ambiguous: the attacker themselves must complete a Google OAuth consent flow, which is the attacker's own action rather than a victim's; UI:N is arguably more precise. AC:H is the most defensible of the disputed metrics, as the attacker must know or enumerate a peer's numeric provider_id. No EPSS data was provided; no CISA KEV listing exists; and no public POC has been identified at time of analysis. Despite the low numeric score, the real-world impact within a multi-user deployment is meaningful: a rogue or compromised backend account silently redirects a colleague's entire appointment feed - including customer PII - to an external calendar with no visible indication to the victim. Defenders should treat the data-exposure outcome as the priority signal rather than the numeric CVSS score, particularly in deployments with multiple backend users.

A secretary or provider account in a multi-user Easy!Appointments instance navigates to the Google OAuth initiation URL, substituting a peer provider's numeric ID (for example, provider_id=5) in place of their own. After clicking through the standard Google OAuth consent page with their own personal Google account, the application writes the resulting token to the victim's database row. From that point forward, every appointment booked with the victim provider is silently mirrored to the attacker's Google Calendar, exposing customer names and email addresses with no visible alert to the victim. No public POC exists at time of analysis, but the technique requires only standard browser requests and a Google account.