Skip to main content

OpenReception Appointment CVE-2026-48071

| EUVDEUVD-2026-54224 MEDIUM
Improper Restriction of Excessive Authentication Attempts (CWE-307)
2026-08-06 security-advisories@github.com
5.8
CVSS 3.1 · Vendor: github
Share

Severity by source

Vendor (github) PRIMARY
5.8 MEDIUM
AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L
vuln.today AI
4.0 MEDIUM

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.

3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:L
4.0 AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L

Primary rating from Vendor (github).

CVSS VectorVendor: github

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Changed
Confidentiality
None
Integrity
None
Availability
Low

Lifecycle Timeline

3
Source Code Evidence Fetched
Aug 06, 2026 - 23:28 vuln.today
Analysis Generated
Aug 06, 2026 - 23:28 vuln.today
Patch available
Aug 06, 2026 - 23:03 EUVD

DescriptionCVE.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.

Share

CVE-2026-48071 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy