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.
Metrics
Affected Vendors & Products
| Vendors | Products |
|---|---|
| Open-reception |
|
No data.
No data.
OpenCVE Enrichment is a feature of OpenCVE that uses AI to automatically link vendors and products to CVEs. Learn more on GitHub.
| Vendors | Products |
|---|---|
| Open-reception |
|
References
History
Fri, 07 Aug 2026 10:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Open-reception
Open-reception appointment-booking-software |
|
| Vendors & Products |
Open-reception
Open-reception appointment-booking-software |
Thu, 06 Aug 2026 22:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | OpenReception's logout page clears local access_token before server-side revocation, leaving duplicated tokens valid until expiry | |
| Weaknesses | CWE-613 | |
| References |
|
|
| Metrics |
cvssV3_1
|
MITRE
Status: PUBLISHED
Assigner: GitHub_M
Published:
Updated: 2026-08-06T21:00:44.615Z
Reserved: 2026-05-20T18:25:25.709Z
Link: CVE-2026-48079
Vulnrichment
No data.
NVD
No data.
Redhat
No data.
OpenCVE Enrichment
Updated: 2026-08-07T09:58:59Z