Severity by source
AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L
AC:H reflects the prerequisite that the victim email must exist in multiple tenants on the same shared instance, which is not universally true; S:C retained because impact crosses the tenant authorization boundary.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
3DescriptionCVE.org
OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.4, the PIN-type challenge throttle uses emailHash as the only key. The throttle rows live in the central challenge_throttle table, which is shared across all tenants. Every tenant's /api/tenants/{id}/appointments/verify-challenge endpoint increments the same row when a PIN response fails, and every tenant's /api/tenants/{id}/appointments/challenge endpoint reads the same row when deciding whether to issue a new challenge. When the same emailHash exists in multiple tenants on the same OpenReception instance (the same patient holding tunnels in two different clinics that share the platform), an attacker who knows the patient's email can lock out that patient on tenant B by issuing failed challenge responses against tenant A. The attacker needs no relationship to tenant B; the lockout propagates through the shared throttle row. The lockout escalates with repeated failures. The first lockout triggers at 4 failed attempts and lasts approximately 60 seconds. Subsequent failures escalate the lockout duration to 5 minutes, 30 minutes, and 60 minutes per the throttle service's escalation logic. Repeated bursts produce sustained denial of service against the targeted email. Version 1.0.4 patches the issue.
AnalysisAI
Cross-tenant PIN challenge throttle isolation failure in OpenReception appointment booking software (prior to 1.0.4) allows unauthenticated remote attackers to lock out a patient on any tenant by submitting failed PIN responses against a different tenant on the same platform instance. The root cause is that the challenge_throttle table is keyed solely by emailHash with no tenant dimension, so throttle state bleeds across tenant boundaries. Lockout escalates from 60 seconds to 60 minutes after repeated failure bursts. No public exploit has been identified at time of analysis, and a vendor patch is available in version 1.0.4.
Technical ContextAI
OpenReception is a multi-tenant, end-to-end encrypted appointment booking platform where multiple healthcare clinics (tenants) share a single instance. PIN-based appointment verification is implemented via challenge/response endpoints (/api/tenants/{id}/appointments/challenge and /api/tenants/{id}/appointments/verify-challenge). Throttle state is persisted in a shared challenge_throttle table keyed only by emailHash. CWE-307 (Improper Restriction of Excessive Authentication Attempts) applies: the throttle mechanism fails to scope its key to the tenant context, creating a cross-tenant side-channel. When the same patient email exists across two tenants (e.g., a patient registered at two clinics both using the same OpenReception instance), increments from failed challenges on tenant A's row directly affect the shared row read by tenant B, producing an unintended cross-tenant DoS. The commit diff references addition of registration-bootstrap tests, consistent with the broader hardening in version 1.0.4.
RemediationAI
Upgrade to OpenReception appointment-booking-software version 1.0.4, which patches the cross-tenant throttle isolation flaw per the vendor advisory at https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-f778-wf9x-3qf9 and the associated fix commit 828b5297dc4c9827f7a43841d0f839c21462185d. The fix should scope the challenge_throttle table key to (tenantId, emailHash) rather than emailHash alone, eliminating the cross-tenant bleed. If immediate upgrade is not possible, a compensating control would be to restrict the verify-challenge endpoints so that challenge attempts are only accepted for email addresses that have an active appointment record within that specific tenant - this would prevent an attacker on tenant A from issuing challenges for emails not registered there, at the cost of some additional lookup latency per request. Rate-limiting challenge requests at the network or API gateway layer per source IP can also reduce burst DoS potential but does not eliminate it if the attacker rotates IPs.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-54224