Easy!Appointments CVE-2026-52839

Exploitation requires a valid authenticated provider-role account within the target Easy!Appointments instance - unauthenticated external attackers cannot exploit this directly. The instance must be running any version prior to 1.6.0. Single-provider deployments have no peer provider to target and are not meaningfully affected; multi-provider instances (clinics, booking platforms, shared scheduling tools) are the realistic attack surface. No non-default configuration is required beyond the presence of more than one registered provider account. The write-before-crash variant on store means the attacker does not need a successful HTTP 200 response to confirm persistence - an HTTP 500 error may accompany a fully committed unauthorized record. Exploitation is limited by the need for provider-role credentials and knowledge of a peer provider's numeric ID.

The assigned CVSS 3.1 score of 3.3 (AV:N/AC:H/PR:H) materially underestimates exploitability. The description explicitly states 'a normal authenticated provider' is the threat actor, which maps to PR:L, not PR:H; and the attack requires only substituting a numeric provider ID in an API parameter - a trivially low-complexity operation, not AC:H. A corrected assessment places this at approximately CVSS 5.3 (Medium). No EPSS data was available for this CVE, and KEV status is not confirmed. The practical blast radius is limited to multi-provider deployments: a clinic, salon, or service business where competing providers share the same instance is the realistic threat model. In that context, schedule injection between peers could enable business disruption, privacy violations between providers, or appointment-booking fraud. The write-before-crash variant on store also complicates detection because error log analysis alone will not reveal successful persistence.

An attacker holding a valid Easy!Appointments provider account enumerates the numeric IDs of peer providers (discoverable via scheduling UI or API), then posts a crafted JSON body to /appointments/store with a substituted id_users_provider referencing the target. The database commits the unauthorized appointment row before the controller crashes, so the victim provider's calendar is modified while the attacker receives only an HTTP error - making the attack look like a failed request in access logs. No public exploit code has been identified at time of analysis.