Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.7",
  "pubDate": "2026-08-06T22:17:10.997Z",
  "pubdate": "2026-08-06T22:17:10.997Z",
  "executiveSummary": "OpenReception's appointment booking software prior to version 1.0.6 suffers from an insufficient proof-of-work difficulty vulnerability within the appointment booking platform.\nThe vulnerability allows unauthenticated clients to bypass intended rate-limiting mechanisms designed to protect the patient booking flow from automated abuse.\nThe affected component is the bootstrap challenge endpoint located at /api/tenants/{id}/appointments/bootstrap-challenge.\nThe risk implication is that automated actors can abuse the patient booking flow with minimal computational friction, as modern hardware can solve the weak proof-of-work challenges in under 200 milliseconds.\nAttackers can leverage arbitrary client-supplied values to generate unique throttle keys, completely circumventing server-side per-binding accumulation controls.\nNo complex authentication or high privileges are required to exploit this flaw, as the endpoint is accessible to unauthenticated network clients establishing tunnels and submitting appointments.",
  "technicalDetails": "The root cause of the vulnerability stems from two primary design weaknesses in the bootstrap challenge endpoint: a deficient cryptographic puzzle difficulty and flawed throttle key derivation.\nThe vulnerable component is the bootstrap challenge endpoint situated at /api/tenants/{id}/appointments/bootstrap-challenge.\nThe endpoint issues a SHA-256 proof-of-work challenge configured with a difficulty of 4 hexadecimal zeros, which corresponds to merely 16 bits of computational work.\nModern hardware processes 16 bits of work in under 200 milliseconds, rendering the cryptographic puzzle decorative rather than effective as a rate-limiter for unauthenticated clients.\nConcurrently, the handler invokes the challengeThrottleService.checkThrottle(binding, \"passkey\") method to enforce rate-limiting.\nHowever, the binding parameter incorporates attacker-controlled values, specifically tunnelId, clientPublicKey, and an optional emailHash.\nBecause these parameters are fully controlled by the client, an attacker can supply new and arbitrary values for each fresh attempt.\nThis behavior produces a unique throttle key per iteration, successfully bypassing the intended per-binding accumulation logic enforced by the server.\nThe attack flow proceeds as follows: an unauthenticated attacker targets the endpoint to initiate the appointment booking workflow.\nThe server issues a SHA-256 proof-of-work challenge requiring only 16 bits of matching hex zeros.\nThe attacker rapidly solves the trivial proof-of-work challenge using standard client hardware almost instantaneously.\nSimultaneously, the attacker randomizes or rotates the attacker-controlled parameters (tunnelId, clientPublicKey, emailHash) in subsequent requests to generate distinct binding keys.\nThis invalidates the tracking mechanisms of challengeThrottleService.checkThrottle, allowing the attacker to evade server-side throttling.\nConsequently, the attacker can continuously solve proof-of-work challenges and submit appointments as fast as the server can issue them.\nThe affected software versions include all instances of OpenReception prior to version 1.0.6.\nNetwork exposure is direct, impacting unauthenticated external clients interacting with the appointment booking platform."
}