Host-Header-Injection in Bestätigungsmails

OpenReception ist eine selbst gehostete, mandantenweise Terminbuchung für Arztpraxen mit Ende-zu-Ende-Verschlüsselung zwischen Clients und Mitarbeitern. Mitarbeiter und Mandanten-Administratoren treten über eine Einladung bei, die sie durch Aufruf eines per E-Mail zugesandten Einmal-Links bestätigen. Wir schätzen die Arbeit des Projekts an einem datenschutzfreundlichen Buchungsdesign und das Engagement der Maintainer bei diesem Report.

Der Host des Bestätigungslinks stammt aus der Anfrage. generateBaseUrl gibt Protokoll, Hostname und Port der Anfrage-URL zurück, ohne Allowlist:

export function generateBaseUrl(url: URL): string {
  const protocol = url.protocol;
  const port = url.port ? `:${url.port}` : "";
  const hostname = url.hostname;
  return `${protocol}//${hostname}${port}`;
}

sendConfirmationEmail baut den Bestätigungslink daraus: const confirmUrl = generateBaseUrl(requestUrl) + "/confirm/" + confirmationCode.

Der Endpunkt, der diese E-Mail auslöst, ist nicht authentifiziert und reicht den Host der Anfrage weiter. POST /api/auth/resend-confirmation nimmt nur eine E-Mail-Adresse entgegen und gibt die Anfrage-url unverändert weiter:

export const POST: RequestHandler = async ({ request, url }) => {
  const body = await request.json();
  await UserService.resendConfirmationEmail(body.email, url);
  // ...
};

UserService.resendConfirmationEmail rotiert den Einladungscode des noch nicht bestätigten Kontos auf ein frisches, zehn Minuten gültiges Token und versendet anschließend den aus dieser Anfrage-url gebauten Link. Die Suche in der zentralen Datenbank erfolgt über die E-Mail-Adresse; ein gefälschter Host ändert daher nur den Host im erzeugten Link, nicht das adressierte Konto. Ein gefälschter Host mit der E-Mail-Adresse einer eingeladenen Person liefert somit eine Bestätigungsmail, deren Bestätigungslink https://attacker.example/confirm/<token> lautet.

Der zugehörige Einladungspfad baut seinen Link in der Produktion aus der vertrauenswürdigen tenant.domain (invite/+server.ts:209); resend-confirmation übergibt die rohe Anfrage-url an generateBaseUrl, sodass dieselbe vertrauenswürdige Domain-Quelle nicht genutzt wird. Dies ist von CVE-2026-48081 zu unterscheiden, das einen javascript:-Link in der E-Mail-Fußzeile betraf; es handelt sich um ein eigenständiges Verhalten im selben E-Mail-Pfad.

Ob ein gefälschter Host die Anwendung erreicht, hängt vom vorgelagerten Proxy ab. Die Standard-docker-compose.prod.yml setzt kein ORIGIN, und das mitgelieferte Caddyfile stellt der App einen :443-Catch-all voran (reverse_proxy app:3000, On-Demand-TLS). Der Catch-all ergibt sich aus dem dynamischen Mandantenmodell: Mandanten fügen eigene Domains hinzu und Caddy stellt Zertifikate auf Anforderung aus, sodass der vorgelagerte Block die Mandanten-vHosts nicht statisch aufzählen kann. Ein Catch-all reicht einen beliebigen Host standardmäßig nach oben weiter, und Caddy bindet den Host nicht an die TLS-SNI; eine Anfrage, die TLS mit einer gültigen Mandanten-SNI aushandelt und dann einen gefälschten Host trägt, erreicht die App mit dem Angreifer-Host. Dieser Zustellweg ist aus dem mitgelieferten Caddyfile und dem Standardverhalten von reverse_proxy abgeleitet; der Proof of Concept richtet sich direkt an die Anwendung und übt die Proxy-Schicht nicht aus.

Ein Betreiber, der den Proxy stattdessen mit expliziten Blöcken pro Mandant und ohne Catch-all konfiguriert, macht den Proxy zu einer Host-Allowlist und ist nicht betroffen; diese Konfiguration ist mit dem On-Demand-Mandanten-Domain-Feature unvereinbar und nicht die Standardeinrichtung.

Sobald der Angreifer das Einmal-Token besitzt, wird das Konto über den eigenen Bestätigungs- und Passkey-Registrierungs-Flow der Anwendung auf der echten Mandanten-Domain beansprucht, die der Angreifer normal erreicht. Der Angreifer registriert einen selbst kontrollierten Passkey und meldet sich an, womit er eine vollständige Session als die eingeladene Person erhält, bevor diese das Konto jemals genutzt hat. Der Login-Schritt fälscht nichts: Nur die resend-confirmation-Anfrage trägt den gefälschten Host.