CVE-2026-58202: OpenReception: Confirmation-email links built from the request Host enable pending-account takeover via `POST /api/auth/resend-confirmation`
OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 2.0.0, the account-confirmation link in emails is built from the request Host header, with no allowlist. The unauthenticated POST /api/auth/resend-confirmation rotates a pending invitee's confirmation token and emails a link whose host comes from the request. An attacker who sends one resend-confirmation with Host: attacker.example and a pending invitee's email causes that invitee to receive a confirmation email whose only link points to the attacker. If the invitee clicks, the one-time confirmation token reaches the attacker, who then confirms the account on the real tenant domain and registers a passkey they control, taking over the account before the legitimate invitee ever uses it. All released versions through v1.1.0 are affected; no patched version exists yet. Reaching the app with a spoofed Host depends on the front proxy: the stock Caddy catch-all forwards it, while an operator who configures explicit per-tenant proxy blocks is not affected (see Details 4). The invite path builds links from the trusted tenant.domain (invite/+server.ts:204-210); the resend-confirmation path builds them from the request Host. This issue has been patched in version 2.0.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
OpenReceptionto a version that resolves this vulnerability.Fixed in 2.0.0 - Compensating control
Configure explicit per-tenant proxy blocks at the front proxy so spoofed Host headers are not forwarded to the application.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
All released versions through v1.1.0 are affected when the front proxy forwards attacker-controlled Host headers. The stock Caddy catch-all configuration does this; deployments using explicit per-tenant proxy blocks are not affected.
What does an attacker need to exploit it?
The attacker needs no account or authentication. They need the email address of a pending invitee and a path to send a resend-confirmation request with a spoofed Host header that reaches the application.
Are existing active accounts affected?
The described attack targets pending invitees whose confirmation token can be rotated through the resend-confirmation endpoint. It enables takeover before the legitimate invitee first uses the account.
What can be done while no patched version is available?
Configure the front proxy with explicit per-tenant proxy blocks so spoofed Host headers do not reach the application. The issue states that this configuration is not affected.
How can an operator determine whether their deployment is vulnerable?
Review the front-proxy configuration to determine whether it accepts and forwards arbitrary Host headers to OpenReception. A stock Caddy catch-all is affected, while explicit per-tenant proxy blocks are not.