OpenReception Appointment Booking CVE-2026-65825

Requires a multi-tenant OpenReception instance (at least two tenants sharing the central challenge_throttle table). The attacker must be able to self-register a client in a second tenant - which the advisory states is unauthenticated self-service - and trigger a failed PIN attempt there so that tenant owns the throttle row keyed on the tenant-independent emailHash (sha256(email)). The attacker must therefore know the victim's email address, and the victim must be a returning client who authenticates with a six-digit booking PIN in the target tenant. Exploitation is limited by high attack complexity: the cross-tenant throttle-ownership setup, the need to know the victim email, and the sustained online brute force of the 10^6 PIN space (hours to a few days on one IP; faster by rotating the unvalidated x-forwarded-for header to neutralize the generic 20-req/2s IP limiter). It does not require authentication (PR:N) or user interaction, and no vendor patch exists, so the main realistic limiters are the email prerequisite, the multi-tenant deployment requirement, and the brute-force time rather than any auth gate.

Signals point to a real but conditional priority rather than a drop-everything emergency. CVSS is 7.5 (High) with AV:N/PR:N/UI:N, i.e. network-reachable and unauthenticated, which looks urgent, but AC:H materially tempers it: the attacker must first make a second tenant own the victim's throttle row, must already know the victim's email to compute the emailHash, and must then grind a 10^6 PIN space over 'hours to a few days' on a single IP. EPSS is not present in the input, so exploitation-probability cannot be quoted. The vuln.today decision label is 'this_week' (not act_now/emergency), consistent with a serious issue that still requires meaningful setup. There is no CISA KEV listing and no indication of active exploitation, so this is not confirmed exploited in the wild; however, the maintainer's GHSA advisory includes a detailed proof-of-concept with reproduction steps and measured results (about 79 guesses/sec locally), so a public PoC reference exists even though it is not verified as standalone working exploit code. A notable aggravating factor is that there is no patch available at publication, so defenders cannot remediate by upgrading. Net: treat as a prioritized fix this week for multi-tenant OpenReception deployments, weighting the lack of a patch and the unauthenticated cross-tenant nature against the high attack complexity and the email/multi-tenant prerequisites. Also note the scoring is debated in the advisory itself - a single-component reading would be S:U/6.5; the S:C/7.5 rests on the cross-tenant boundary crossing.

An attacker who knows a victim's email self-registers as a client in a second tenant on the same OpenReception instance and triggers a failed PIN attempt there, making that tenant permanently own the shared throttle row for the victim's emailHash. With the brute-force throttle now inert in the victim's tenant (and the IP rate limiter trivially evaded by rotating x-forwarded-for), the attacker brute-forces the six-digit PIN online over hours to days, recovering the booking access token to read the client's end-to-end-encrypted appointment tunnel and add or cancel their appointments. A maintainer-published PoC reference describing these exact steps exists, though it is not verified as working standalone exploit code.