CVE-2026-58202: OpenReception: Confirmation-email links built from the request Host enable pending-account takeover via `POST /api/auth/resend-confirmation`

Published Oct 23, 2026
·
Updated

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

1 affected component
OpenReception OpenReception<=1.1.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade OpenReception to a version that resolves this vulnerability.

    Fixed in 2.0.0
  2. Compensating control

    Configure explicit per-tenant proxy blocks at the front proxy so spoofed Host headers are not forwarded to the application.

Event History

Oct 23, 2026
CVE Published
via MITRE·08:27 PM
Data Sourced
via MITRE·08:27 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

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.

2

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.

3

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.

4

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.

5

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203