Skip to main content

OpenReception CVE-2026-48079

| EUVDEUVD-2026-54150 HIGH
Insufficient Session Expiration (CWE-613)
2026-08-06 security-advisories@github.com
7.4
CVSS 3.1 · Vendor: github
Share

Severity by source

Vendor (github) PRIMARY
7.4 HIGH
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
vuln.today AI
7.4 HIGH

AC:H reflects the prerequisite of prior token possession by the attacker; C:H/I:H reflect unrestricted authenticated API access; no availability impact applies.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
4.0 AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (github).

CVSS VectorVendor: github

Attack Vector
Network
Attack Complexity
High
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

Lifecycle Timeline

4
Patch available
Aug 06, 2026 - 23:03 EUVD
Source Code Evidence Fetched
Aug 06, 2026 - 23:00 vuln.today
Analysis Generated
Aug 06, 2026 - 23:00 vuln.today
CVE Published
Aug 06, 2026 - 22:17 cve.org
HIGH 7.4

DescriptionCVE.org

OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.2, when a user navigates to the /logout page, the page's server-side load handler deletes the access_token cookie before calling /api/auth/logout via an internal event.fetch(). The internal fetch consequently runs without the auth cookie, so apiAuthHandle rejects it, the logout handler never executes, and SessionService.revokeSession() is never called for the current session. The DB session row remains valid until its natural expiry (one week by default). The user sees a successful logout (cookie gone, UI returns to login), but any party still holding a copy of the now-deleted access token can continue making authenticated API calls until the session naturally expires. The root cause is a simple ordering mistake. The same auth subsystem implements the correct order in /api/auth/logout: revoke the current DB session first, then delete the cookie. The page-level wrapper does the opposite. Version 1.0.2 initiates server-side logout before removing authentication cookies and first appears in version 1.0.2. Version 2.0.0 later replaces this with a race-free client-side logout flow.

AnalysisAI

OpenReception's appointment booking platform (prior to v1.0.2) leaves server-side sessions active for up to one week after a user explicitly logs out, due to an operation-ordering bug in the SvelteKit logout route. An attacker who has already obtained a copy of the victim's access token - through network interception, browser storage access on a shared device, or another independent theft vector - can continue making fully authenticated API calls against the platform even after the victim believes their session has ended. No public exploit has been identified at time of analysis and no CISA KEV listing exists, but the C:H/I:H impact reflects unrestricted access to the victim's appointment API surface for the duration of the unexpired session.

Technical ContextAI

The application is a SvelteKit-based web platform using server-side page load handlers (+page.server.ts) and SvelteKit's internal event.fetch() for same-origin API calls. CWE-613 (Insufficient Session Expiration) identifies the root cause class: the /logout route's load handler invoked removeAuthCookies(event) inside a .finally() block, unconditionally deleting the access_token cookie before the internal fetch to /api/auth/logout could complete authentication. Because credentials: 'same-origin' requires the cookie to be present for apiAuthHandle to authenticate the request, the revocation call was always rejected, and SessionService.revokeSession() never executed. The database session row persisted with its default one-week TTL. The same auth subsystem implemented the correct ordering in the API handler itself - revoke first, then clear cookies - making this an isolated page-wrapper regression rather than a systemic design failure. No CPE strings were provided in the source intelligence.

RemediationAI

Upgrade to OpenReception version 1.0.2 or later, which removes the broken server-side logout handler entirely and replaces it with a client-side fetch that correctly sends the access_token cookie to /api/auth/logout before clearing local auth state. Version 2.0.0 provides a further-hardened race-free variant of the same client-side approach. The fix is delivered via commits 2419f9e87a8abad72f31b1fedeb80c758b30322e and f833dbf50059ff7d4ea42ce7bbb3a5cdcf7a6929 (https://github.com/open-reception/appointment-booking-software/commit/2419f9e87a8abad72f31b1fedeb80c758b30322e). If patching is not immediately possible, the only meaningful compensating control is to reduce the database session TTL from its default one week to the shortest value the user experience allows (e.g., 1-2 hours); this shrinks the post-logout exploitation window at the cost of more frequent re-authentication for legitimate users. No other workaround fully closes the flaw, because the revocation call itself never reaches the database under the vulnerable code path.

Share

CVE-2026-48079 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy