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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-08-06T22:17:10.557Z",
  "pubdate": "2026-08-06T22:17:10.557Z",
  "executiveSummary": "OpenReception appointment booking software prior to version 1.0.2 suffers from a flawed logout sequence vulnerability.\nThe vulnerability allows a user's session to remain active on the backend database despite the user interface indicating a successful logout.\nThe affected product is OpenReception appointment booking software in versions prior to 1.0.2.\nThe risk implication is that orphaned sessions persist in the database until their natural expiration, leaving authenticated API endpoints exposed if an attacker acquires a copy of the access token.\nAn attacker who has previously captured or retained a copy of the deleted access token can leverage this capability to continue making unauthorized authenticated API calls.\nExploitation requires the attacker to possess a previously valid access token belonging to the target user while the underlying database session remains unrevoked.",
  "technicalDetails": "The root cause of the vulnerability is a simple ordering mistake within the server-side load handler of the /logout page.\nWhen a user navigates to the /logout page, the server-side load handler deletes the access token cookie prior to invoking /api/auth/logout via an internal event.fetch() call.\nBecause the access token cookie is deleted first, the internal event.fetch() request executes without the necessary authentication context.\nConsequently, the apiAuthHandle function rejects the request, the backend logout handler never executes, and SessionService.revokeSession() is never called for the active session.\nAs a result of this flawed control flow, the database session row remains valid until its natural expiry, which defaults to one week.\nThe attack flow proceeds as follows: 1) The victim navigates to the /logout page, believing their session is securely terminated. 2) The server prematurely deletes the access token cookie from the client. 3) The internal logout API call fails authentication due to the missing cookie, preventing database-level session revocation. 4) An attacker possessing a copy of the pre-deletion access token utilizes it to issue authenticated API requests. 5) The server accepts the token because the corresponding session remains active in the database.\nThe vulnerable component is the page-level logout wrapper handling the /logout route.\nAffected versions include all OpenReception versions prior to 1.0.2.\nAuthentication requirements dictate that a valid session and access token must have existed prior to the logout attempt, with the attacker possessing a retained copy of the token.\nNo elevated privileges are required beyond holding a valid access token.\nThe vulnerability is exposed over the network via HTTP request handling.\nPost-exploitation impact includes unauthorized API access and session hijacking via leaked or stored access tokens until the backend session naturally expires after one week."
}