Session hijacking via sess_user_publicv2_* cookie — cross-browser account takeover

Bug Reports
1

The session cookie `sess_user_publicv2_*` is not bound to the originating browser, IP address, or user-agent. Copying the cookie value to a different browser session grants full authenticated access to the victim’s account — including all booking history — without any credentials.

Steps to reproduce:

  1. Log in to .simplybook.me with Account A (normal browser). mean your tenant slug
  2. Open DevTools → Application → Cookies → *.simplybook.me.
  3. Copy the value of `sess_user_publicv2_testingsecure` (e.g. gs0fluki7krklqqhjhe4om3ge5).
  4. Open a second browser in Incognito mode (no existing session).
  5. Navigate to .simplybook.me/v2/#client/bookings/type/all . mean your tenant slug
  6. Open DevTools → Application → Cookies and manually set `sess_user_publicv2_testingsecure` to the copied value.
  7. Refresh the page.

Result:
The second browser is now fully authenticated as Account A and displays all bookings (booking codes, dates, provider names, appointment history) without ever entering credentials.

Recommended solution

Bind sessions to a fingerprint of the originating user-agent and/or IP on creation, and reject reuse if the fingerprint changes(create link hashed based access ). Set the session cookie with the HttpOnly, Secure, and SameSite=Strict flags. Implement short session expiry with re-authentication for sensitive actions.

2

Hi, thank for report. However it cannot be accepted.

It is how sessions work in internet. And it is actually bind to IP address.

But opening browser in incognito mode does not change your IP address.

Also there is no steps how to stole cookies.

3

Thank you for the clarification.

I understand that Incognito mode does not change the IP address and that session cookies are intended to maintain authentication.

However, the issue I am reporting is that possession of the sess_user_publicv2_* cookie alone appears sufficient to obtain full access to the authenticated account from a different browser profile. This demonstrates that the session token functions as a bearer credential.

The security concern is not the method of obtaining the cookie but the impact if the cookie is exposed through any realistic scenario, such as:

  • Browser extensions

  • Malware on the endpoint

  • Physical access to an unlocked workstation

  • Browser backup/sync mechanisms

  • Session leakage through other vulnerabilities

Steps to reproduce:

  1. Log in to .simplybook.me with Account A (normal browser). mean your tenant slug

  2. Open DevTools → Application → Cookies → *.simplybook.me.

  3. Copy the value of `sess_user_publicv2_testingsecure` (e.g. gs0fluki7krklqqhjhe4om3ge5).

  4. Open a second browser in Incognito mode (no existing session).

  5. Navigate to .simplybook.me/v2/#client/bookings/type/all . mean your tenant slug

  6. Open DevTools → Application → Cookies and manually set `sess_user_publicv2_testingsecure` to the copied value.

  7. Refresh the page.

4

As i mentioned already it is bind to IP address.