How We Exploited a Shared Guest Session to Steal Password Reset Tokens — Without Any Authentication

Some of the most dangerous vulnerabilities don't originate from traditional attack vectors — they emerge from subtle architectural decisions in how user sessions are managed. In this write-up, we detail a critical vulnerability our team discovered in a cloud-based employee monitoring platform during a bug bounty engagement, where a flawed guest session mechanism allowed any unauthenticated attacker to silently steal password reset tokens and other sensitive URLs visited by legitimate users — all without any user interaction.

For confidentiality, the target company's name and identifying URLs have been redacted throughout this post.

Target Overview

The target was a multi-tenant employee monitoring and insider threat prevention SaaS platform. Each organization is provisioned with a dedicated subdomain instance (<instance>.[redacted].co) hosting their monitoring dashboards, user management, and administrative panels.

As part of the password recovery flow, the application exposes a POST /password/reset endpoint. Under normal operation, this endpoint accepts an email address, a new password, and a token parameter — redirecting the user to /login upon success.

Discovering the Shared Guest Session

While auditing the authentication flow, we identified a critical architectural flaw: the application used a single, shared guest session for all unauthenticated users on the same instance. This meant that when any visitor — authenticated or not — browsed a URL on the instance, that URL was stored in a server-side guest session object that was globally accessible.

The guest session was not scoped per-user, per-browser, or per-IP. It was a single shared object across the entire tenant instance. Any URL visited by any user would overwrite the previous value, and any subsequent unauthenticated request triggering a redirect would pull from this shared state.

This alone is a serious session isolation failure. But the real question was: how far could we escalate this?

Escalation — From Information Leak to Account Takeover

We quickly realized the POST /password/reset endpoint was the perfect vehicle to weaponize this flaw. When submitted without the token parameter and without a Referer header, the endpoint didn't return an error — instead, it issued a 302 Found redirect to whatever URL was last stored in the shared guest session.

This meant we could silently harvest any URL that any user on the instance had recently visited — including password reset token links. Here's how we demonstrated the full exploit chain:

Step 1 — Victim Clicks a Password Reset Link

The victim receives a legitimate password reset email and clicks the link — completely standard behavior:

https://[redacted]/password/reset/yTgaemMXw9ZwVZUeW-Cr

The moment the victim's browser loads this URL, it gets written into the shared guest session on the server.

Step 2 — Attacker Harvests the Token

From a completely separate machine with zero credentials, we submitted the following unauthenticated POST request. Two conditions are critical: the token parameter must be omitted, and the Referer header must not be present:

POST /password/reset HTTP/1.1
Host: [redacted]
Content-Type: application/x-www-form-urlencoded
Cache-Control: max-age=0
Connection: close

email=attacker%40example.com&password=test&password_confirmation=test

Step 3 — Server Returns the Victim's Reset Token

The server responded with a 302 Found, and the Location header contained the victim's password reset token URL — served directly from the shared guest session:

HTTP/1.1 302 Found
Server: nginx
Location: https://[redacted]/password/reset/yTgaemMXw9ZwVZUeW-Cr
Cache-Control: max-age=0, no-store, private

The following screenshot shows the full request and response captured in Burp Suite. The password reset token is clearly visible in the Location header and the HTML redirect body:

We repeated the test across multiple scenarios. In this instance, the victim had last visited /password/remind, and the server once again leaked that URL to our unauthenticated request — confirming the flaw was not endpoint-specific:

Step 4 — Full Account Takeover

With the stolen password reset token in hand, the attacker navigates directly to the leaked URL and sets a new password for the victim's account — achieving complete account takeover without ever interacting with the victim.

Root Cause

The vulnerability stemmed from a shared guest session that was globally accessible across all users on the same tenant instance:

• When any user visited a URL on the instance, that URL was stored in a server-side guest session object.
• This guest session was not isolated per-user or per-browser — it was a single shared object for the entire instance.
• Any unauthenticated request that triggered a redirect would pull the last-visited URL from this shared session and return it in the Location header.

This is a fundamental session isolation failure at the application architecture level.

Impact

The impact of this vulnerability extends well beyond password reset tokens:

Key factors that elevate the severity:

• Zero authentication — The attacker needs no credentials, no cookies, no tokens of any kind.
• Zero user interaction — The victim simply browses the application normally. No phishing, no social engineering required.
• Silent exploitation — There is no indication to the victim that their URLs are being harvested.
• Broad applicability — Any URL visited by any user on the instance is exposed, not just password reset links.

Remediation Recommendations

1. Isolate guest sessions per-user. Each unauthenticated visitor must receive a unique, independent session. A globally shared guest session across a multi-user instance violates the fundamental principle of session isolation.
2. Sanitize redirect targets. The Location header in redirect responses should never reflect URLs from another user's browsing context. Redirect destinations should be statically defined or bound to the current authenticated session.
3. Enforce the Referer header defensively. While the absence of Referer was a precondition for this exploit, relying on client-sent headers for security is not a sufficient mitigation. Server-side session isolation is the proper fix.