Skip to content
Heist/ feed
Back to feed
High

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

Type: advisorySources: OSV

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.

Products
Not specified
Affected versions
Not specified
Fixed versions
Not specified
CVEs
CVE-2026-58202
Confirmed fixed CVEs
Not specified
Updated in this feed
7 Nov 2026, 13:25 UTC · Revision 1

Source evidence

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

core-osv · Original source

Published 23 Oct 2026, 20:27 UTC

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.

osv:CVE-2026-58202
Complete source record
{
  "id": "3bc8aee60bcb0f81ed0c40e57f6de5582c522f7fb4eb0b8634cf7be352ba490a",
  "url": "https://osv.dev/vulnerability/CVE-2026-58202",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "OpenReception: Confirmation-email links built from the request Host enable pending-account takeover via `POST /api/auth/resend-confirmation`",
    "summary": "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.",
    "evidence": "osv:CVE-2026-58202",
    "products": [],
    "severity": "high",
    "structured": {
      "id": "CVE-2026-58202",
      "aliases": [
        "CVE-2026-58202",
        "GHSA-w5g9-g2p4-2g4m"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:L"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://github.com/open-reception/appointment-booking-software",
              "type": "GIT",
              "events": [
                {
                  "introduced": "0"
                },
                {
                  "fixed": "51ef46d25d72c35bb4b69e018ddf64570668051b"
                },
                {
                  "fixed": "df5432776a1a5b47c3a64d64e9d05dbe2b7a7819"
                }
              ],
              "database_specific": {
                "extracted_events": [
                  {
                    "range": [
                      {
                        "introduced": "0"
                      },
                      {
                        "fixed": "2.0.0"
                      }
                    ],
                    "source": "AFFECTED_FIELD",
                    "strategy": "StringRangeExpression"
                  },
                  {
                    "range": [
                      {
                        "fixed": "df5432776a1a5b47c3a64d64e9d05dbe2b7a7819"
                      }
                    ],
                    "source": "REFERENCES_COMMIT"
                  },
                  {
                    "range": [
                      {
                        "fixed": "51ef46d25d72c35bb4b69e018ddf64570668051b"
                      }
                    ],
                    "source": "REFERENCES_TAG",
                    "original_tag": "v2.0.0"
                  }
                ]
              }
            }
          ],
          "versions": [
            "v1.1.1",
            "v1.1.0",
            "v1.0.9",
            "v1.0.8",
            "v1.0.7",
            "v1.0.6",
            "v1.0.5",
            "v1.0.4",
            "v1.0.2",
            "v1.0.1",
            "v1.0.0",
            "v1.0.0-rc2",
            "v1.0.0-rc"
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-58202.json"
          }
        }
      ],
      "modified": "2026-10-31T02:31:00.051446917Z",
      "provider": "osv",
      "references": [
        "https://github.com/open-reception/appointment-booking-software/releases/tag/v2.0.0",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/58xxx/CVE-2026-58202.json",
        "https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-w5g9-g2p4-2g4m",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-58202",
        "https://github.com/open-reception/appointment-booking-software/commit/df5432776a1a5b47c3a64d64e9d05dbe2b7a7819"
      ],
      "provider_metadata": {
        "cwe_ids": [
          "CWE-640"
        ],
        "cna_assigner": "GitHub_M",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/58xxx/CVE-2026-58202.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-58202",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 519447,
  "published_at": "2026-10-23T20:27:36.09+00:00"
}