Description

OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.1, a fully provisioned OpenReception instance accepts unauthenticated POST requests to `/setup/create-admin-account` and creates additional GLOBAL_ADMIN accounts without verifying that an admin already exists. Any unauthenticated network attacker who can submit a same-origin form POST gains full platform-level administrative control. The newly created account is `is_active=true` with `confirmation_state=ACCESS_GRANTED` and does not require completing email confirmation; the GLOBAL_ADMIN row is created active and immediately usable. Login and tenant enumeration succeed without any further interaction. This is distinct from the deployment race condition already documented on the `Claiming an instance` page. That documented race covers the window between deployment and first claim. The bug reported here works after the operator has properly claimed and configured the instance: the layout-level guard that protects the setup page only redirects on GET, while the `default` form action handler creates the user without rechecking `adminExists()`. Three GLOBAL_ADMIN accounts were created in succession during testing, with no rate limiting observed. Audit-specific event logging beyond standard application logs was not assessed; the standard `[error]` line that surfaces only when a uniqueness conflict is hit is not the same as a security event for "additional admin created post-claim". The form post is rejected for browser drive-by CSRF by SvelteKit's built-in same-origin check, but any tool that supplies a matching `Origin` header (curl, Burp, automated scanners, server-side proxies) bypasses this trivially. No additional preconditions exist. Users should upgrade to version 1.0.1 to receive a patch.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-06T22:17:11.440Z",
  "pubdate": "2026-08-06T22:17:11.440Z",
  "executiveSummary": "OpenReception appointment booking software prior to version 1.0.1 suffers from an improper access control vulnerability that allows unauthenticated network attackers to create arbitrary GLOBAL_ADMIN accounts.\nThe vulnerability affects OpenReception instances prior to version 1.0.1, specifically targeting the unauthenticated endpoint located at /setup/create-admin-account.\nThe core risk implication is complete platform-level administrative compromise, allowing an attacker to gain full control over the application, access tenant enumeration capabilities, and compromise the confidentiality, integrity, and availability of the underlying appointment booking platform.\nAttacker capabilities include unauthenticated remote exploitation over the network, bypassing intended setup guards post-deployment, and generating active administrator credentials without requiring email confirmation or prior authentication.\nExploitation requirements are minimal, necessitating only an unauthenticated network attacker capable of submitting a crafted HTTP POST request with a matching Origin header to bypass SvelteKit's built-in same-origin check, as observed with tools like curl, Burp Suite, automated scanners, or server-side proxies.",
  "technicalDetails": "The root cause of the vulnerability resides in flawed endpoint protection and state validation within OpenReception prior to version 1.0.1. Specifically, the layout-level guard intended to protect the setup page exclusively redirects incoming HTTP GET requests, while the default form action handler responsible for processing account creation fails to re-evaluate whether an administrator already exists via the adminExists() function.\nThe vulnerable component is the administrative setup handler associated with the /setup/create-admin-account path. The affected software versions include all OpenReception deployments prior to version 1.0.1.\nAuthentication and privilege requirements are entirely absent; the endpoint accepts unauthenticated POST requests even after the platform has been fully provisioned, claimed, and configured by an authorized operator.\nNetwork exposure is direct, as the application accepts these malicious payloads over standard web protocols from any network attacker capable of reaching the instance.\nThe attack flow proceeds as follows: First, the attacker targets the fully provisioned OpenReception instance and bypasses browser-based drive-by Cross-Site Request Forgery (CSRF) protections by utilizing automated tools, proxies, or command-line utilities such as curl or Burp Suite to supply a matching Origin header. Second, the attacker sends an unauthenticated HTTP POST request directly to the /setup/create-admin-account endpoint. Third, the application processes the form action payload without verifying if an administrator account has already been provisioned. Fourth, the backend successfully creates the new GLOBAL_ADMIN account with is_active=true and confirmation_state=ACCESS_GRANTED, entirely omitting email confirmation requirements. Finally, multiple administrator accounts can be created sequentially in the absence of rate limiting.\nPost-exploitation impact includes immediate platform-level administrative control, successful tenant enumeration without further interaction, and persistent unauthorized access via the newly provisioned GLOBAL_ADMIN credentials."
}