EUVD-2026-54155Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
Bypass requires only supplying fresh random binding values per request - trivially scripted - making AC:L more accurate than the vendor-assigned AC:H; no confidentiality or integrity impact applies.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
3DescriptionCVE.org
OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.6, the bootstrap challenge endpoint at /api/tenants/{id}/appointments/bootstrap-challenge issues a SHA-256 proof-of-work with difficulty=4 hex zeros, equivalent to 16 bits of work. Modern hardware solves this in under 200 milliseconds, providing essentially no friction against automated abuse of the patient booking flow. Proof-of-work is used in the booking flow as a rate-limiter for unauthenticated clients establishing tunnels and submitting appointments. At 16 bits of difficulty, the construct is decorative rather than effective. An attacker can solve PoW challenges as fast as the server can issue them, defeating the rate-limiting purpose. The handler also calls challengeThrottleService.checkThrottle(binding, "passkey"), but the binding includes attacker-controlled values (tunnelId, clientPublicKey, and optional emailHash). For each fresh attempt, the attacker can supply new values, producing a new throttle key and bypassing the per-binding accumulation. Practical abuse friction is therefore the PoW difficulty itself, not a stable per-IP or per-email server-side throttle. Version 1.0.6 fixes the issue.
AnalysisAI
Rate-limiting in OpenReception's appointment booking software prior to version 1.0.6 is defeated by two compounding weaknesses: a SHA-256 proof-of-work configured at only 16 bits of difficulty (solvable in under 200ms on modern hardware) and a per-binding throttle service whose key is derived entirely from attacker-controlled parameters. Remote unauthenticated attackers can automate high-volume requests to the /api/tenants/{id}/appointments/bootstrap-challenge endpoint - rotating fresh tunnelId and clientPublicKey values each attempt to generate a new throttle namespace - bypassing both controls and flooding the patient appointment booking flow. No public exploit code has been identified at time of analysis, and this vulnerability does not appear in the CISA KEV catalog.
Technical ContextAI
The endpoint /api/tenants/{id}/appointments/bootstrap-challenge issues SHA-256 proof-of-work challenges to throttle unauthenticated clients before they establish end-to-end encrypted booking tunnels and submit appointments. The difficulty constant NEW_CLIENT_BOOTSTRAP_DIFFICULTY was hardcoded to 4, requiring the SHA-256 digest to begin with 4 hexadecimal zeros (16 bits of work), which averages only 2^16 = 65,536 hash iterations - trivially fast on any modern CPU. CWE-770 (Allocation of Resources Without Limits or Throttling) is the root cause: the PoW provides negligible computational friction. Compounding this, the secondary control challengeThrottleService.checkThrottle(binding, 'passkey') builds its throttle key from the fields tunnelId, clientPublicKey, and optional emailHash, all of which are supplied by the caller with no server-side binding to IP address or verified identity. An attacker generating fresh random values for these fields on each request produces a distinct throttle namespace per attempt, preventing per-binding accumulation from ever triggering a block.
RemediationAI
Upgrade to OpenReception appointment-booking-software version 1.0.6, confirmed by commit e9c96c049ebf558df7a9e4c5c93f6fe2b092c8c6 and the vendor security advisory at https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-hm9g-mh7x-657g. The patch raises NEW_CLIENT_BOOTSTRAP_DIFFICULTY from 4 to 5 hexadecimal zeros (16 bits to 20 bits, approximately 16x more computational work per challenge). Operators should be aware that 20-bit PoW (~1M hash iterations) remains solvable in a few seconds on modern hardware, so the patch meaningfully raises the bar but does not constitute a robust rate-limit on its own. As a supplementary control, deploy IP-based rate limiting at the reverse-proxy or WAF layer (e.g., nginx limit_req_zone or Cloudflare rate limiting targeting the bootstrap-challenge path) to address the throttle-key bypass, which the PoW difficulty increase does not fully resolve - the underlying flaw of attacker-controlled throttle keys is not patched in this release.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today