Host-Header Injection in Confirmation Emails

OpenReception is self-hosted, per-tenant appointment booking for medical practices, with end-to-end encryption between clients and staff. Staff and tenant administrators join through an invite that they confirm by following a one-time link emailed to them. We appreciate the project's work on a privacy-preserving booking design and the maintainers' engagement on this report.

The confirmation link's host comes from the request. generateBaseUrl returns the protocol, hostname, and port of the request URL, with no 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 builds the confirmation link from it: const confirmUrl = generateBaseUrl(requestUrl) + "/confirm/" + confirmationCode.

The endpoint that triggers this email is unauthenticated and forwards the request Host. POST /api/auth/resend-confirmation takes only an email and passes the request url straight through:

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

UserService.resendConfirmationEmail rotates the pending account's invite code to a fresh token valid for ten minutes, then emails the link built from that request url. The lookup is keyed by email in the central database, so a forged Host changes only the host in the generated link, not which account is targeted. A forged Host with a pending invitee's email therefore delivers a confirmation email whose confirmation link is https://attacker.example/confirm/<token>.

The sibling invite path builds its link from the trusted tenant.domain in production (invite/+server.ts:209); resend-confirmation passes the raw request url to generateBaseUrl, so the same trusted-domain source is not used. This is distinct from CVE-2026-48081, which concerned a javascript: link in the email footer; it is a separate behavior in the same email path.

Whether a spoofed Host reaches the application depends on the front proxy. The stock docker-compose.prod.yml sets no ORIGIN, and the shipped Caddyfile fronts the app with a :443 catch-all (reverse_proxy app:3000, on-demand TLS). The catch-all follows from the dynamic multi-tenant model: tenants add their own domains and Caddy issues certificates on demand, so the front block cannot statically enumerate tenant vhosts. A catch-all forwards an arbitrary upstream Host by default, and Caddy does not pin the Host to the TLS SNI, so a request that negotiates TLS with a valid tenant SNI and then carries a spoofed Host reaches the app with the attacker host intact. This delivery path is reasoned from the shipped Caddyfile and standard reverse_proxy behavior; the proof of concept targets the application directly and does not exercise the proxy layer.

An operator who instead configures explicit per-tenant proxy blocks with no catch-all turns the proxy into a Host allowlist and is not affected; that configuration is incompatible with the on-demand tenant-domain feature and is not the stock setup.

Once the attacker holds the one-time token, the account is claimed through the application's own confirm and passkey-registration flow on the real tenant domain, which the attacker reaches normally. The attacker registers a passkey they control and logs in, obtaining a full session as the invitee before the invitee has ever used the account. The login step spoofs nothing: only the resend-confirmation request carries the forged Host.