CVE-2026-54460 in appointment-booking-software
Summary
by MITRE • 09/18/2026
OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to 1.1.1, POST /api/auth/passkeys accepts a request-body userId and attacker-supplied passkey without an authenticated session, does not call WebAuthnService.verifyRegistration, and does not bind enrollment to locals.user.id. An unauthenticated attacker who knows the public tenant ID and the target staff email can use the public booking bootstrap and GET /api/tenants/[id]/appointments/staff-public-keys to obtain candidate userId values. The attacker first causes UserService.addAdditionalPasskey to store a controlled public key for a candidate userId, then attempts login with the target email; the login check compares verificationResult.userId with the email-resolved account and reveals whether the injected credential belongs to that target. Repeating this injection-before-login sequence identifies the matching userId, and the normal login endpoint accepts the attacker's assertion for the stored key and creates a STAFF session. The session can expose tenant data and reveal TENANT_ADMIN identifiers for further takeover; GLOBAL_ADMIN accounts are not reachable through this tenant-scoped path. A hijacked TENANT_ADMIN can modify or delete tenant resources and key shares, potentially making appointment data permanently undecryptable and taking booking services offline. This issue is fixed in version 1.1.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability resides within the authentication module of OpenReception's appointment booking software, specifically affecting versions prior to 1.1.1. The core technical flaw lies in the POST /api/auth/passkeys endpoint, which handles WebAuthn passkey registration and verification logic. This endpoint fails to enforce proper session binding during the enrollment phase. Specifically, when processing a request body containing a userId and an attacker-supplied public key, the system does not invoke the necessary WebAuthnService.verifyRegistration function to validate the cryptographic proof of possession against the user's identity context. Furthermore, the implementation neglects to bind the newly enrolled passkey credential to the locals.user.id variable, which is typically used to ensure that a registration operation is performed by an authenticated session belonging to the intended account owner. This architectural oversight allows any actor with network access to associate arbitrary cryptographic keys with specific user identifiers without prior authentication or proper identity verification.
The exploitation of this vulnerability relies on a combination of information disclosure and logical manipulation. An unauthenticated attacker can leverage public endpoints, such as GET /api/tenants/[id]/appointments/staff-public-keys, to retrieve candidate userId values associated with staff members in a known tenant. By combining these publicly available identifiers with the target's email address, an attacker can construct malicious registration requests. The attack proceeds by first injecting a controlled public key into the system for a specific candidate userId via the vulnerable endpoint. Subsequently, the attacker attempts to log in using that same credential paired with the target staff member's email. Because the login mechanism compares the verificationResult.userId derived from the injected passkey against the account resolved from the provided email, it inadvertently creates an oracle side-channel. If the user ID associated with the stored key matches the one linked to the email address, the system accepts the authentication; otherwise, it rejects it based on a mismatched identity context.
This discrepancy allows for a precise identification of valid target accounts through iterative testing. By repeating the injection-before-login sequence across multiple candidate userIds, an attacker can systematically determine which user ID corresponds to the intended victim's account. Once the correct mapping is established and the passkey is successfully bound to that userId in the backend database, the attacker gains full control over the associated session. The normal login endpoint subsequently accepts assertions signed by this maliciously enrolled key, granting the attacker a valid STAFF session token without ever knowing the legitimate user's private keys or biometric data. This effectively bypasses multi-factor authentication protections provided by WebAuthn, as the system trusts the server-side record of credential ownership rather than verifying real-time cryptographic proof against an authenticated context during enrollment.
The operational impact of this vulnerability is severe, particularly for tenants utilizing TENANT_ADMIN roles. A hijacked session allows the attacker to access sensitive tenant data and manipulate critical configuration settings. Most critically, a compromised TENANT_ADMIN account can modify or delete key shares associated with end-to-end encryption mechanisms. Since appointment data in OpenReception relies on these keys for confidentiality, their removal or alteration renders the encrypted records permanently undecryptable by legitimate users. This constitutes a destructive denial of service that destroys data integrity and availability rather than merely disrupting uptime. Additionally, the attacker can take booking services offline through administrative actions. While GLOBAL_ADMIN accounts remain out of reach due to tenant-scoped isolation limits, the compromise of any single TENANT_ADMIN account provides significant leverage for espionage or sabotage within that specific organizational boundary.
From a classification perspective, this vulnerability aligns with CWE-287, which covers Improper Authentication, as well as CWE-640, Weak Key Management, due to the improper binding of cryptographic credentials to user identities. In terms of MITRE ATT&CK mapping, the initial enumeration and credential injection phase corresponds to T1595.001 Active Scanning: Vulnerability Scanning, while the exploitation step represents T1078 Valid Accounts, specifically through account hijacking via misconfigured authentication flows. The subsequent destruction of key shares falls under T1486 Data Encrypted for Impact, as it prevents authorized access to data by removing decryption capabilities. Mitigation requires immediate upgrading to version 1.1.1 or later, where the WebAuthnService.verifyRegistration function is correctly invoked during passkey enrollment and strict session binding ensures that credentials are only associated with authenticated user contexts. Until patching occurs, administrators should restrict public API access to staff-public-keys endpoints if possible and monitor for anomalous authentication patterns involving new passkey registrations followed immediately by successful logins from untrusted IP addresses or unusual geographic locations.