Description

OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.2, the registration handler at `POST /api/auth/register/{userId}` validates the relationship between the WebAuthn challenge and the registration cookie's email but never validates that the `userId` in the URL belongs to that email. An unauthenticated attacker requests a challenge for their own email, generates a registration response with their own authenticator, and submits it against any victim user's URL. The challenge-vs-cookie email match passes, the WebAuthn ceremony validates, and `addPasskey` writes the attacker's credential into the victim's `user_passkey` rows. The next victim-email login accepts a passkey assertion from the attacker's authenticator and issues a session as the victim. User IDs are not strictly secret on this platform, but the exact set of exposure surfaces should be assessed by the maintainers. Staff-list endpoints return user IDs to authenticated tenant members per the route signature; live verification of all exposure surfaces (whether user IDs leak through any unauthenticated route, through invite-confirmation URLs, or through other administrative views) is part of the pending live PoC. Where the attacker knows the victim's email and userId, the analysis below becomes account takeover. Version 1.0.2 fixes the issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-06T22:17:11.750Z",
  "pubdate": "2026-08-06T22:17:11.750Z",
  "executiveSummary": "OpenReception's appointment booking software prior to version 1.0.2 is vulnerable to an authentication bypass and account takeover vulnerability residing in its WebAuthn registration handler. The flaw stems from a failure to validate the relationship between the URL parameter userId and the authenticated email associated with the WebAuthn challenge and registration cookie during the registration ceremony. An unauthenticated attacker capable of acquiring their own valid WebAuthn challenge can supply an arbitrary victim's userId within the endpoint path, causing the server to associate the attacker's cryptographic passkey credentials with the victim's account record in the database. Successful exploitation allows the attacker to bypass multi-factor and primary authentication mechanisms completely, yielding full account takeover of the targeted user upon subsequent passkey assertion logins. The risk implication is critical, as compromise of a tenant member or administrative user grants unauthorized access to sensitive appointment data and administrative functions. Exploitation requires the attacker to know or discover the target victim's email and userId, which may be obtainable through ancillary endpoints such as staff-list routes or invite-confirmation workflows. Mitigation requires upgrading to version 1.0.2 or later, which correctly enforces authorization checks between the URL-supplied userId and the session or cookie context during passkey registration.",
  "technicalDetails": "The vulnerability resides in the registration handler endpoint located at POST /api/auth/register/{userId} within OpenReception prior to version 1.0.2. The root cause of the flaw is an improper authorization check during the WebAuthn registration ceremony. While the application correctly validates the cryptographic relationship between the WebAuthn challenge and the email address stored in the registration cookie, it completely omits verification that the userId specified in the URL path maps to that same email address.\nThe attack flow proceeds as follows. First, an unauthenticated attacker initiates a standard WebAuthn registration process for their own email address, obtaining a valid challenge and registration cookie. Next, the attacker crafts a malicious request targeting the POST /api/auth/register/{userId} route, substituting their own userId in the URL path with the targeted victim's userId while retaining their own registration cookie and WebAuthn authenticator response payload.\nUpon receiving the request, the backend server successfully validates the challenge against the registration cookie's email and verifies the WebAuthn cryptographic ceremony. Because the authorization logic fails to cross-reference the URL-supplied userId with the email tied to the active registration session, the addPasskey function proceeds to write the attacker's public key credential into the victim's user_passkey database rows. Consequently, the attacker's authenticator is bound to the victim's account.\nIn the post-exploitation phase, during any subsequent login attempt for the victim's email address, the system accepts passkey assertions originating from the attacker's registered authenticator and successfully issues an active user session authenticated as the victim. User IDs may be exposed via various ancillary surfaces, such as staff-list endpoints returning user IDs to authenticated tenant members or potentially through invite-confirmation URLs and administrative views. Affected versions include all deployments of OpenReception prior to version 1.0.2. The vulnerability requires network exposure of the API endpoint, an unauthenticated attacker capable of registering an authenticator, and knowledge of both the victim's email address and userId."
}