SECURITYCRITICALCVE-2026-54460

CVE-2026-54460: OpenReception Unauthenticated Passkey Injection

A missing auth check on OpenReception's passkey endpoint lets unauthenticated attackers inject WebAuthn credentials and take over staff accounts.

Dylan H.

Security Team

September 18, 2026
3 min read
CVE-2026-54460: OpenReception Unauthenticated Passkey Injection

Critical severity

Rated critical. Prioritise patching — see the remediation guidance below.

Affected Products

  • OpenReception appointment-booking-software up to and including 1.1.0

Executive Summary

OpenReception, an end-to-end encrypted appointment-booking platform used by medical practices, has patched a critical unauthenticated account-takeover vulnerability tracked as CVE-2026-54460 (CVSS 9.8). The endpoint that registers a new WebAuthn passkey, POST /api/auth/passkeys, accepted an attacker-supplied userId and public key without requiring a logged-in session and without running any part of the actual WebAuthn registration ceremony — letting a remote, unauthenticated attacker plant their own passkey on a staff account and log in as that user.

The issue is fixed in OpenReception 1.1.1 (GitHub advisory GHSA-g233-m625-m3pc).


Vulnerability Overview

AttributeValue
CVE IDCVE-2026-54460
CVSS Score9.8 (Critical), vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWECWE-306: Missing Authentication for Critical Function
ComponentPOST /api/auth/passkeys
AffectedOpenReception appointment-booking-software ≤ 1.1.0
Fixed Version1.1.1
DisclosedJune 4, 2026 (credited to Volker Schönefeld and Simon Weber)
GitHub AdvisoryGHSA-g233-m625-m3pc

Root Cause and Attack Chain

POST /api/auth/passkeys is meant to let an already-logged-in user add a new passkey to their own account. Instead, the handler:

  • Never reads locals.user — it doesn't check who, if anyone, is authenticated.
  • Never calls WebAuthnService.verifyRegistration — it skips the actual WebAuthn ceremony (server-issued challenge, attestation, origin check, RP ID check) entirely.
  • Trusts the request body's userId and attacker-supplied public key directly, binding the new credential to whatever account ID the caller specifies.

Chaining this into a full account takeover requires the attacker to identify a valid target:

  1. Using the public tenant ID and the target staff member's email, the attacker calls the public booking bootstrap and GET /api/tenants/[id]/appointments/staff-public-keys to enumerate candidate userId values.
  2. The attacker injects a passkey they control against a candidate userId via the vulnerable endpoint, then attempts to log in with the target's email.
  3. The login response reveals whether verificationResult.userId matches the email-resolved account — confirming the correct userId and completing the takeover.

This is a close cousin of an earlier, already-patched bug (CVE-2026-48087) in the companion bootstrap endpoint POST /api/auth/register/[id], which received the same class of fix months prior. That earlier fix, however, did not extend to /api/auth/passkeys, which retained the original unauthenticated-injection primitive until this advisory.


Impact

A successful exploit gives an unauthenticated attacker full takeover of a tenant staff or administrator account on an appointment platform explicitly marketed as end-to-end encrypted for medical practices — putting patient scheduling data and any account-accessible PHI at risk.


Remediation

  1. Upgrade to OpenReception 1.1.1 or later immediately. The fix requires an authenticated session on POST /api/auth/passkeys, binds new credentials to the logged-in user, and enforces the full WebAuthn ceremony (server challenge, origin, and RP ID validation).
  2. Audit the userPasskey table for credentials added without a preceding registration challenge, and treat any such record as compromised.
  3. Force re-registration of passkeys for all staff accounts after upgrading.
  4. Have staff review their own accounts for unrecognized passkeys or active sessions.

References