{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-48079 in the wild and no public exploit code.","fix":"No fix has been published for CVE-2026-48079 yet. Limit exposure of the affected software until one is available.","what":"CVE-2026-48079 is a high-severity vulnerability in open-reception appointment-booking-software, published on 6 Aug 2026. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-48079 and fix it if it is affected.\n\nWhat it is: CVE-2026-48079 is a high-severity vulnerability in open-reception appointment-booking-software, published on 6 Aug 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-48079 in the wild and no public exploit code.\n\nAffected product: open-reception appointment-booking-software. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-48079/ (Markdown: https://insights.sbomify.com/CVE-2026-48079/index.md)","id":"CVE-2026-48079","markdown":"https://insights.sbomify.com/CVE-2026-48079/index.md","name":"CVE-2026-48079","record":{"aliases":["GHSA-hrhm-m2hm-7cjh"],"analysis":{"component_type":"web_application","fix_type":"upgrade","impacts":["account_takeover","security_bypass"],"network_reachable":"yes","non_default_config":false,"product_category":"Appointment booking software","requires_auth":"none","summary":"Attackers can retain valid session tokens after user logout due to improper cookie deletion order, allowing continued unauthorized access until session expiry.","user_interaction":"not_required","vuln_class":"security_feature_bypass"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"GitHub_M","cpe":[],"cvss":{"score":7.4,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N","version":"3.1"},"cwes":[{"id":"CWE-613","name":"DEPRECATED: Insufficient Session Expiration"}],"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.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":false,"headline":"Security feature bypass in appointment-booking-software","id":"CVE-2026-48079","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"security_feature_bypass","year":"2026"},"n_packages":0,"n_references":3,"next":{"headline":"Information disclosure in appointment-booking-software","id":"CVE-2026-48080"},"packages":[],"prev":{"headline":"OpenReception's schedule endpoint discloses isPublic=false channels and slot availability to unauthenticated callers","id":"CVE-2026-48078"},"products":["appointment-booking-software"],"published":"2026-08-06","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"no","exploitation":"none","technical_impact":"total"},"state":"PUBLISHED","updated":"2026-08-07","vendors":["open-reception"]},"summary":"Attackers can retain valid session tokens after user logout due to improper cookie deletion order, allowing continued unauthorized access until session expiry.","url":"https://insights.sbomify.com/CVE-2026-48079/"}