EUVD-2026-54157Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Network endpoint requires no prior auth (AV:N/PR:N), but success is probabilistic on passphrase guessing (AC:H); full account takeover with no availability impact (C:H/I:H/A:N).
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
4DescriptionCVE.org
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.
AnalysisAI
Unlimited passphrase brute-force is possible against any known account in OpenReception's appointment booking platform prior to version 1.0.2, because the /api/auth/login endpoint's passphrase branch never invokes the existing challengeThrottleService that correctly rate-limits the WebAuthn path. The asymmetry - confirmed by the fix commit wiring the same throttle infrastructure into the passphrase branch - means an unauthenticated remote attacker can sustain roughly 10 passphrase guesses per second per account, bounded only by Argon2 verification cost. Combined with a 12-character minimum policy that enforces no entropy or dictionary checks, accounts using common base patterns are realistically compromised in days on a single CPU or hours on a small GPU cluster. No public exploit code or CISA KEV listing has been identified at time of analysis.
Technical ContextAI
CWE-307 (Improper Restriction of Excessive Authentication Attempts) describes the root cause: server-side controls that should cap failed authentication attempts are absent on one code path while present on another. OpenReception supports two login modalities - WebAuthn passkeys and passphrases - both routed through the same SvelteKit backend. The challengeThrottleService was already wired to the WebAuthn challenge endpoint and returns HTTP 429 after approximately 19 failed attempts. The passphrase branch in src/routes/api/auth/login/+server.ts never called checkThrottle() or recordFailedAttempt(), leaving it completely unguarded. Argon2 is used for passphrase verification, which introduces a natural ~100 ms per-attempt delay on the tested host, but at that rate an attacker can still sustain approximately 10 attempts per second. The fix in commit b283dbb670e09112299fb0cf89f3cb054ecc1700 adds 'passphrase' as a valid ThrottleType and inserts pre-authentication throttle checks and post-failure recording into the passphrase handler, mirroring what the WebAuthn path already did. No CPE string was provided in the available intelligence data.
RemediationAI
Upgrade to OpenReception version 1.0.2, which resolves the issue by extending the existing challengeThrottleService to cover the passphrase authentication path. The patch is delivered in commit b283dbb670e09112299fb0cf89f3cb054ecc1700 and is detailed in the GitHub Security Advisory at https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-hhg5-xmjg-3m93. If immediate upgrade is not feasible, operators should deploy reverse-proxy or WAF rate-limiting rules targeting POST requests to /api/auth/login - note that IP-based rate limiting may block legitimate users sharing NAT or VPN egress addresses, and is bypassable by distributed botnets, so it is a partial compensating control only. As a complementary measure, enforcing a stricter passphrase policy with entropy and dictionary-rejection checks reduces the success probability of any brute-force attempt but does not substitute for server-side throttling. Account lockout notifications and anomalous login alerting on volume spikes provide detection coverage during the remediation window.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today