Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.8",
  "pubDate": "2026-08-06T22:17:09.680Z",
  "pubdate": "2026-08-06T22:17:09.680Z",
  "executiveSummary": "A cross-tenant denial of service vulnerability exists in OpenReception appointment booking software prior to version 1.0.4. The vulnerability arises from improper handling of rate-limiting state where the PIN-type challenge throttle relies exclusively on the emailHash identifier within a centrally shared challenge_throttle table across all tenants. This design flaw allows an attacker who knows a target patient's email address to trigger repeated failed challenge responses against one tenant, thereby incrementing the global throttle counter and locking out the same patient across completely unrelated tenants on the same instance. Exploitation requires no privileges or relationship to the victim tenant, making it possible to mount a sustained denial of service attack against targeted users. The impact includes disruption of appointment booking capabilities and operational denial of service. The vulnerability is successfully addressed in version 1.0.4 by implementing proper tenant-isolated rate-limiting logic.",
  "technicalDetails": "The vulnerability stems from insufficient context isolation within the rate-limiting and challenge verification mechanisms of OpenReception prior to version 1.0.4. Specifically, the vulnerable component is the PIN-type challenge throttle service operating on the central database table challenge_throttle, which is shared globally across multi-tenant boundaries. The root cause is the reliance on emailHash as the sole composite key for tracking failed authentication attempts, omitting the tenant identifier from the throttling key structure.\nThe attack flow proceeds as follows: First, an attacker identifies a victim's email address and maps multiple tenants on the same OpenReception instance where the victim holds appointments or patient profiles. The attacker targets the endpoint /api/tenants/{id}/appointments/verify-challenge on tenant A, submitting deliberately invalid PIN responses associated with the victim's emailHash. Because the challenge_throttle table is shared globally, these failed attempts increment the shared throttle row regardless of the originating tenant context.\nSubsequently, when the victim attempts to interact with tenant B via the endpoint /api/tenants/{id}/appointments/challenge, the application reads the same shared throttle row to determine whether to issue a new challenge. Due to the accumulated failures generated on tenant A, the throttle service's escalation logic triggers. The first lockout initiates at 4 failed attempts, imposing an initial 60-second lockout. Repeated failure bursts escalate this duration to 5 minutes, 30 minutes, and 60 minutes per cycle. By continuously issuing automated failed requests against tenant A, an attacker can maintain a persistent denial of service condition against the victim on tenant B.\nThe exploitation requirements are minimal: the attacker needs no authentication, holds no privileges, and requires no prior relationship or access to the targeted tenant B. Network exposure is present via the standard web APIs exposed by the appointment booking platform. The payload behavior consists of automated HTTP POST requests directed at verification endpoints with incorrect PIN inputs. Post-exploitation impact is strictly limited to availability, manifesting as localized denial of service and service disruption for targeted users attempting to book appointments across shared instances."
}