{"id":"CVE-2026-48074","aliases":["EUVD-2026-54258","GHSA-6f8g-wfxp-mqxw"],"status":"published","title":"OpenReception: Staff deletion removes pending invites cross-tenant by email match","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.","severity":{"version":"3.1","score":2.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N","level":"low","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00292,"percentile":0.21975,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":false},"cwes":["CWE-863"],"published":"2026-08-06T20:27:21Z","modified":"2026-10-28T02:30:24Z","products":[{"vendor":"open-reception","product":"appointment-booking-software"}],"references":[{"url":"https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-6f8g-wfxp-mqxw","tags":["x_refsource_CONFIRM","exploit","advisory"]},{"url":"https://github.com/open-reception/appointment-booking-software/commit/5e77fd1df4262d09bfa6b59acfec4f66408de570","tags":["x_refsource_MISC","fix"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/48xxx/CVE-2026-48074.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-48074","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-48074","title":"OpenReception: Staff deletion removes pending invites cross-tenant by email match","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.","status":"published","published":"2026-08-06T20:27:21.24Z","modified":"2026-08-07T17:02:59.982Z","cvss":[{"version":"3.1","score":2.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N","level":"low","assessor":"cna"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T14:19:47.998488Z"}],"euvd":[{"id":"EUVD-2026-54258","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.","status":"published","published":"2026-08-06T20:27:21Z","modified":"2026-08-07T17:02:59Z","cvss":[{"version":"3.1","score":2.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N","level":"low"}],"updated_at":"2026-11-02T18:02:06.930016Z"}],"nvd":[{"id":"CVE-2026-48074","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.","status":"published","published":"2026-08-06T22:17:09.833Z","modified":"2026-10-23T21:10:00.157Z","cvss":[{"version":"3.1","score":2.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N","level":"low","assessor":"secondary"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T14:12:35.386166Z"}],"osv":[{"id":"CVE-2026-48074","title":"OpenReception: Staff deletion removes pending invites cross-tenant by email match","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.","status":"published","published":"2026-08-06T20:27:21.24Z","modified":"2026-10-28T02:30:24.986386795Z","cvss":[{"version":"3.1","score":2.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N","level":"low"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T15:45:06.701612Z"}]}}