CVE-2026-65824 in Appointment Booking Software
Summary
by MITRE • 10/24/2026
OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 2.2.1, an attacker who captures a pending invite token can replay it to obtain a passkey-registration credential and register their own passkey on the invited account, taking control of that account. For a staff or tenant-admin invite this yields access to the tenant context tied to that account. This issue has been patched in version 2.2.1.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/24/2026
The vulnerability identified in OpenReception's appointment booking software prior to version 2.2.1 represents a critical authentication bypass and session management flaw rooted in the improper handling of invite tokens during the passkey registration process. The platform utilizes end-to-end encryption for its core data, yet this security boundary was circumvented at the identity verification stage. Specifically, the system failed to enforce strict binding between an invitation token and the specific user context or time-bound constraints necessary to prevent reuse. This architectural oversight allows a threat actor who intercepts a pending invite token during transmission or storage to exploit it for unauthorized account takeover. The flaw is not merely about data interception but rather the lack of single-use validation, enabling replay attacks where the same cryptographic credential can be utilized multiple times by different entities if they possess the captured value.
From a technical perspective, this vulnerability aligns with CWE-294, which describes authentication bypass through capture-replay mechanisms, and CWE-613, concerning insufficient session expiration. The operational impact is severe because it allows an attacker to register their own passkey on a victim's account without needing the victim's password or multi-factor authentication credentials in the traditional sense. Once the attacker registers a new passkey using the replayed invite token, they gain full administrative control over that specific user profile. For staff members and tenant administrators, this access extends beyond personal data to include the entire tenant context associated with their role. This means an attacker can potentially manipulate appointment schedules, access sensitive client information, modify system configurations, or escalate privileges within the multi-tenant architecture of the software.
The exploitation scenario typically involves a network-based adversary who monitors traffic between the client application and the server during the initial invitation acceptance phase. By capturing the unique identifier token sent to validate the user's eligibility for passkey registration, the attacker can subsequently send this same token in a new authentication request from their own device or environment. Since the backend service validates the existence of the token but fails to verify that it has not already been consumed or is still within its valid temporal window relative to the original requester, the system erroneously grants access. This failure highlights a gap in state management where the lifecycle of an invitation credential was not strictly tied to a single successful authentication event.
Mitigation strategies for this vulnerability primarily involve upgrading to version 2.2.1 or later, which addresses these logic flaws by implementing robust token invalidation upon first use and enforcing stricter temporal constraints on invite validity. In environments where immediate patching is not feasible, administrators should ensure that network traffic containing invitation tokens is protected via TLS with strict certificate validation to prevent man-in-the-middle interception. Additionally, implementing short-lived expiration windows for all authentication-related tokens reduces the attack window significantly. Security teams should also monitor for anomalous login patterns or multiple passkey registrations from different geographic locations associated with a single account as an indicator of compromise. This incident underscores the importance of treating invitation mechanisms with the same rigor as primary authentication protocols, ensuring that every step in the identity lifecycle is bound to specific context and time constraints to prevent replay attacks.