Description

OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Versions prior to 1.0.2 don't throttle failed passphrase login attempts. An attacker can submit unlimited wrong passphrase guesses against any known email address, capped only by the Argon2 verification cost (about 100 milliseconds per attempt on the tested host, giving 10 attempts per second sustained). The same backend implements a working per-account throttle on the WebAuthn challenge endpoint, which returns HTTP 429 after roughly 19 attempts. The passphrase branch simply does not invoke that throttle, leaving a supported high-value login path unprotected against credential stuffing and dictionary attacks. The asymmetry confirms this is an oversight rather than a design choice. The throttle infrastructure exists, is wired into the same auth backend, and works on the WebAuthn path. The passphrase branch in `/api/auth/login` was not updated to record failed attempts. Combined with the application's minimum-passphrase policy (12 characters, no entropy or dictionary checks), accounts using common base patterns such as `Spring2026!XX` or words from a leak corpus are realistically reachable in days on a single CPU, hours on a small GPU farm. Version 1.0.2 patches the issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-08-06T22:17:11.297Z",
  "pubdate": "2026-08-06T22:17:11.297Z",
  "executiveSummary": "OpenReception appointment booking software versions prior to 1.0.2 suffer from a missing rate limiting vulnerability on passphrase-based login attempts.\nThe vulnerability allows remote attackers to perform high-speed credential stuffing and dictionary attacks against known email addresses without being throttled by the application.\nWhile the backend implements a working per-account throttle on the WebAuthn challenge endpoint that triggers HTTP 429 after roughly 19 attempts, the passphrase branch in the authentication logic fails to invoke this existing throttle infrastructure.\nCombined with the application's minimum-passphrase policy requiring only 12 characters without entropy or dictionary checks, accounts utilizing common base patterns or leak corpus words are vulnerable to rapid compromise.\nAn attacker can sustain approximately 10 attempts per second on a single CPU limited only by the Argon2 verification cost.\nSuccessful exploitation grants unauthorized access to user accounts, enabling data theft and appointment manipulation.\nThe risk is mitigated in version 1.0.2, which patches the oversight by enforcing appropriate throttling on the passphrase login path.",
  "technicalDetails": "The vulnerability resides in the authentication backend of OpenReception, specifically within the passphrase handling logic exposed at the /api/auth/login endpoint.\nThe root cause is an oversight where the passphrase branch of the authentication controller fails to record failed login attempts and invoke the application's existing rate-limiting infrastructure.\nEvidence of this asymmetry is demonstrated by the WebAuthn challenge endpoint, which correctly implements a per-account throttle returning an HTTP 429 status code after approximately 19 failed attempts.\nBecause the passphrase authentication flow bypasses this tracking, attackers face no artificial delays or blocking mechanisms other than the computational cost of the Argon2 password hashing algorithm.\nOn the tested host, Argon2 verification requires about 100 milliseconds per attempt, permitting a sustained rate of 10 verification cycles per second.\nThe attack flow proceeds as follows: an attacker targets a known email address and initiates automated POST requests to /api/auth/login containing candidate passphrases.\nThe server processes each request through the Argon2 verification function without checking or incrementing a failure counter for the target account.\nLeveraging the application's minimum-passphrase policy of 12 characters lacking entropy enforcement or dictionary checks, attackers can test predictable patterns such as Spring2026!XX or entries from breach corpuses.\nA single CPU can achieve domain coverage in days, while a small GPU farm can reduce this window to hours.\nAuthentication and privilege requirements for the attacker are minimal, as the endpoint is exposed externally to unauthenticated users over the network.\nPost-exploitation impact includes full account takeover, unauthorized access to end-to-end encrypted appointment booking data, and potential lateral movement depending on user privileges."
}