---
id: "CVE-2026-58202"
kind: "vulnerability"
aliases: ["CVE-2026-58202"]
title: "OpenReception: Host header poisoning lets attackers take over invited accounts"
severity: "high"
cvss: 8.3
epss: 0.00429
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["appointment-booking", "caddy", "openreception", "package", "self-hosted"]
not_affected_if: ["explicit-per-tenant-proxy-blocks", "version-2.0.0-or-later"]
published_at: "2026-10-23T21:17:24+00:00"
first_seen_at: "2026-10-23T21:57:34+00:00"
updated_at: "2026-10-25T12:38:49+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58202", "first_seen_at": "2026-10-23T21:57:34+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-58202", "first_seen_at": "2026-10-25T12:38:49+00:00"}]
---

# OpenReception: Host header poisoning lets attackers take over invited accounts

OpenReception builds account-confirmation links in emails from the request Host header, and an unauthenticated resend-confirmation request can make a pending invitee receive a link pointing to an attacker's host. If the invitee clicks, the attacker captures the one-time token, confirms the account and registers their own passkey.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the OpenReception version: releases through `v1.1.0` are affected.
- Check the front proxy config: the stock Caddy catch-all forwards arbitrary Host headers, while explicit per-tenant proxy blocks are not affected.

## Fix

- Upgrade OpenReception to `2.0.0`, which contains the fix.
- Until upgraded, configure explicit per-tenant proxy blocks in Caddy so arbitrary Host headers are not forwarded (unknown whether this fully mitigates beyond the sources' description).

## Timeline

- 2026-10-23T21:57:34+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-58202
- 2026-10-25T12:38:49+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-58202

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_