Nicht authentifizierte WebAuthn-Passkey-Injection

OpenReception ist eine selbst gehostete, mandantenweise Terminbuchung für Arztpraxen mit Ende-zu-Ende-Verschlüsselung zwischen Clients und Mitarbeitern. Mitarbeiter und Mandanten-Administratoren authentifizieren sich mit WebAuthn-Passkeys. Wir schätzen die Arbeit des Projekts an einem datenschutzfreundlichen Buchungsdesign und die zügige Behebung durch die Maintainer.

Der Endpunkt zum Hinzufügen eines Passkeys zu einem Konto, POST /api/auth/passkeys, erfordert keine authentifizierte Session und führt keine WebAuthn-Registrierungszeremonie durch. Der Handler liest eine userId und einen Public Key aus dem Request-Body und speichert sie:

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",
  });
};

Der Handler liest niemals locals.user und verifiziert weder eine vom Server ausgestellte Challenge noch eine Attestation, einen Origin oder eine RP ID. UserService.addAdditionalPasskey speichert den gelieferten Public Key auf dem Zielkonto; die einzige Hürde ist, dass sich das Konto nicht mehr im Zustand INVITED befindet, sodass jedes bestätigte Konto akzeptiert wird.

Die Anfrage erreicht keine Authentifizierungs-Guard. Die API-Middleware weist nicht authentifizierte Anfragen nur für Pfade unter /api/admin ab; bei jeder anderen /api/*-Route wird erwartet, dass der jeweilige Handler die Session selbst prüft, was dieser nicht tut. Die OpenAPI-Annotation des Endpunkts kennzeichnet ihn als authentifizierungspflichtig. Der Handler enthält keine Session-Prüfung.

Beim Login verifiziert POST /api/auth/login die WebAuthn-Assertion gegen den für das Konto gespeicherten Public Key und stellt eine Session aus. Da der gespeicherte Schlüssel der des Angreifers ist, verifiziert dessen Assertion und für das betroffene Konto wird eine vollständige Session ausgestellt.

Die Ziel-userId ist nicht geheim. GET /api/tenants/[id]/appointments/staff-public-keys gibt für jeden Mitarbeiter mit aktiver Krypto { userId, publicKey } zurück, abgesichert nur durch ein Buchungs-Access-Token, das jeder anonyme Besucher über den öffentlichen Buchungs-Bootstrap erzeugt (eine Proof-of-Work-Challenge, deren Token in der Antwort zurückgegeben wird). Ein Angreifer, der die E-Mail-Adresse eines Mitarbeiters kennt, erhält dessen userId, injiziert einen Passkey und meldet sich an.

Der zugehörige Bootstrap-Endpunkt POST /api/auth/register/[id] wurde mit CVE-2026-48087 gegen Passkey-Injection gehärtet. Diese Änderung greift bei /api/auth/passkeys nicht, das das ursprüngliche Injection-Primitiv behält; dieses Advisory behandelt den verbleibenden Endpunkt.

Der nicht authentifizierte Pfad übernimmt ein STAFF-Konto eines Mandanten. Aus einer übernommenen STAFF-Session legt das Mitarbeiterverzeichnis des Mandanten TENANT_ADMIN-Konten mit deren userId und E-Mail offen, sodass dieselbe Injection zum Mandanten-Administrator eskaliert. Ein GLOBAL_ADMIN hat keine Mandantenzuordnung und erscheint in keiner mandantenbezogenen Auflistung, ist über diese Kette also nicht erreichbar.

Eine übernommene Session entschlüsselt für sich genommen keine Klientendaten. OpenReception leitet den Entschlüsselungsschlüssel jedes Mitarbeiters bei der Anmeldung aus dessen Authenticator ab und bindet die gespeicherten Key-Shares an den Credential, mit dem sie registriert wurden; der injizierte Passkey erzeugt daher eine authentifizierte Session, aber nicht das Schlüsselmaterial, das die verschlüsselte Termin-Payload schützt. Offengelegt werden dadurch die Metadaten des Mandanten, personenbezogene Mitarbeiterdaten sowie die Integrität und Verfügbarkeit jedes Termindatensatzes, nicht jedoch die verschlüsselte Klienten-Payload.