Unauthenticated WebAuthn Passkey Injection

OpenReception is self-hosted, per-tenant appointment booking for medical practices, with end-to-end encryption between clients and staff. Staff and tenant administrators authenticate with WebAuthn passkeys. We appreciate the project's work on a privacy-preserving booking design and the maintainers' prompt fix.

The endpoint that adds a passkey to an account, POST /api/auth/passkeys, requires no authenticated session and runs no WebAuthn registration ceremony. The handler reads a userId and a public key from the request body and stores them:

export const POST: RequestHandler = async ({ request }) => {
  const body = await request.json();
  if (!body.userId || !body.passkey) { /* 400 */ }
  if (!body.passkey.id || !body.passkey.publicKey) { /* 400 */ }
  const counter = WebAuthnService.extractCounterFromCredential(body.passkey);
  await UserService.addAdditionalPasskey(body.userId, {
    id: body.passkey.id,
    userId: body.userId,
    publicKey: body.passkey.publicKey,
    counter,
    deviceName: body.passkey.deviceName || "Unknown Device",
  });
};

The handler never reads locals.user and never verifies a server-issued challenge, an attestation, an origin, or an RP ID. UserService.addAdditionalPasskey stores the supplied public key on the target account; the only gate is that the account is not still in the INVITED state, so any confirmed account is accepted.

The request never reaches an authentication guard. The API middleware rejects unauthenticated requests only for paths under /api/admin; every other /api/* route is expected to check the session in its own handler, and this one performs no check. The endpoint's OpenAPI annotation marks it as requiring authentication. The handler contains no session check.

At login, POST /api/auth/login verifies the WebAuthn assertion against the public key stored for the account and issues a session. Because the stored key is the attacker's, the attacker's assertion verifies and a full session is issued for the victim account.

The target userId is not secret. GET /api/tenants/[id]/appointments/staff-public-keys returns { userId, publicKey } for every staff member with active crypto, gated only by a booking access token that any anonymous visitor mints through the public booking bootstrap (a proof-of-work challenge whose token is returned in the response). An attacker who knows a staff member's email address obtains that member's userId, injects a passkey, and logs in.

The companion bootstrap endpoint POST /api/auth/register/[id] was hardened against passkey injection in CVE-2026-48087. That change does not apply to /api/auth/passkeys, which retains the original injection primitive; this advisory covers the remaining endpoint.

The unauthenticated path takes over a tenant STAFF account. From a hijacked STAFF session, the tenant staff listing exposes TENANT_ADMIN accounts with their userId and email, so the same injection escalates to tenant administrator. A GLOBAL_ADMIN has no tenant association and appears in no tenant-scoped listing, so it is not reachable through this chain.

A hijacked session does not by itself decrypt client data. OpenReception derives each staff member's decryption key from their authenticator during login and binds the stored key shares to the credential that registered them, so the injected passkey produces an authenticated session but not the key material that protects the encrypted appointment payload. The exposure is therefore the tenant's metadata, staff personal data, and the integrity and availability of every appointment record, not the encrypted client payload.