Description

OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.6, when a TENANT_ADMIN deletes an existing staff user, the underlying `StaffService.deleteStaffMember()` runs an additional invite cleanup that deletes from the central `user_invite` table by email. The `email` clause has no `tenantId` predicate. Any pending invite in any tenant that shares the deleted staff's email is removed. A TENANT_ADMIN of tenant A who deletes a staff record with email `victim[@]example[.]com` also deletes the pending invite for `victim[@]example[.]com` in tenant B, even though they have no relationship to tenant B. The user-side delete is correctly scoped (`eq(user.id, staffId), eq(user.tenantId, tenantId)`), and the pending-invite-only delete path (when `staffId` is itself an invite ID) is also tenant-scoped. The bug is specifically in the invite cleanup that runs as a side effect of deleting an existing staff user. Version 1.0.6 patches the issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "2.7",
  "pubDate": "2026-08-06T22:17:09.833Z",
  "pubdate": "2026-08-06T22:17:09.833Z",
  "executiveSummary": "OpenReception appointment booking software prior to version 1.0.6 suffers from a cross-tenant data deletion vulnerability stemming from improper authorization enforcement during staff member removal operations.\nThe vulnerability type is categorized as a Broken Access Control or Insecure Direct Object Reference (IDOR) variant, specifically manifesting as a missing multi-tenant boundary check during side-effect database queries.\nThe impact allows a malicious or compromised TENANT_ADMIN from one tenant to arbitrarily delete pending user invitations belonging to entirely unrelated tenants, provided the target email address matches the deleted staff member's email.\nAffected systems include OpenReception instances running software versions prior to 1.0.6, impacting the central user_invite data store across multi-tenant deployments.\nThe risk implications include unauthorized disruption of onboarding processes, denial of service for administrative workflows in victim tenants, and potential information leakage regarding pending invitations through error or state observation.\nAttacker capabilities require authenticated access with TENANT_ADMIN privileges within any valid tenant on the target OpenReception instance.\nExploitation requirements are minimal, needing only the ability to identify or guess an email address associated with a pending invite in another tenant and invoking the standard staff deletion functionality for a locally managed user record sharing that email.",
  "technicalDetails": "The vulnerability resides in the backend invite cleanup routine executed during the deletion of an existing staff user within OpenReception.\nThe vulnerable component is identified as the `StaffService.deleteStaffMember()` function, which orchestrates the removal of staff records and triggers a cascading cleanup of associated records in the central `user_invite` table.\nThe root cause of the vulnerability is the absence of a `tenantId` predicate within the SQL delete clause utilized during the secondary invite cleanup operation. While the primary user-side deletion correctly scopes execution using `eq(user.id, staffId)` combined with `eq(user.tenantId, tenantId)`, and standalone invite deletion paths properly enforce tenant scoping, the side-effect cleanup query relies solely on the email attribute.\nBecause the `email` clause lacks a corresponding tenant boundary check, any pending invite residing in the central database across any tenant that shares the email string of the deleted staff member is targeted and removed.\nThe step-by-step attack flow proceeds as follows: First, an attacker authenticates to the OpenReception platform with TENANT_ADMIN privileges assigned to Tenant A. Second, the attacker creates or identifies a staff record within Tenant A that shares an email address with a known or targeted pending invitation in Tenant B (e.g., victim@example.com). Third, the attacker initiates the deletion of this staff member via the standard management interface, invoking `StaffService.deleteStaffMember()`. Fourth, the application successfully removes the staff record scoped to Tenant A. Fifth, the internal side-effect cleanup routine executes against the central `user_invite` table using only the email identifier. Sixth, the database query matches and deletes the pending invitation in Tenant B due to the omitted `tenantId` filter.\nAffected software versions include all OpenReception deployments prior to version 1.0.6. Authentication and privilege requirements mandate an active session as a TENANT_ADMIN. The attack vector is exposed locally over the application's standard API endpoints used for administrative management."
}