When a Password Reset Is Not Enough: Discovering Inconsistent Session Revocation in Galaxus

TL;DR

Recently I have been trying to get a better understanding of different authentication login and password recovery flows. That led me to first discover the finding described in my previous post.

While exploring password reset flows, I tested Galaxus and found what I describe in the following sections. The finding ultimately came down to a simple observation:

• the same cookie that received a 401 response from the refresh endpoint received a 200 response from an account update endpoint.

Context

Assume an attacker has already authenticated to a victim account and obtained a valid session. The victim becomes aware of the compromise; perhaps through a login notification email—and resets their password expecting the attacker to be removed from the account.

The application uses cookie-based sessions with a lifetime of approximately 20 minutes. After a password reset, the refresh endpoint immediately recognizes the existing session as invalid.

The question was whether every authenticated endpoint enforced that decision consistently.

One Cookie, Two Decisions

The first thing I tested was the token refresh endpoint.

First, I reset the password from the victim’s browser. Using a session cookie captured before the password reset (from the attacker’s session):

GET /auth/v1/refresh-token

the server returned:

401 Unauthorized

At this point, the behavior looked correct.

Next, I sent the same cookie to a GraphQL mutation responsible for updating user information:

POST /api/graphql/update-user

The result:

200 OK

The mutation executed successfully and the victim account data changed.

To verify the result, I confirmed that:

• The cookie value was identical in both requests, i.e., before and after password reset
• The GraphQL response contained populated data.
• The GraphQL errors array was empty.
• The changes appeared immediately in the victim’s active session.

Repeated requests continued to succeed until the session naturally expired approximately 20 minutes later.

The cookie from the attacker’s session was still working after the password reset from the victim.

The refresh endpoint treated the session as revoked. The mutation endpoint did not.

Impact

During the revocation window, an attacker with a pre-existing authenticated session could continue performing account modifications despite the victim having reset their password.

Depending on available account functionality, this may allow modification of recovery information and other security-sensitive account data during the revocation window. In testing, changing the account email required no additional verification. From there, resetting the password via the new email address resulted in full account takeover.

The unique risk is not only that the attacker gains new privileges. It is that the victim’s primary recovery action, that is resetting their password, does not immediately terminate the attacker’s ability to modify account data.

Vendor Response

Galaxus assessed the issue as a known and accepted risk, citing additional controls that reduce the practical impact of the revocation window.

Recommendation

Password reset should invalidate sessions consistently across all authenticated endpoints.

Possible approaches include:

• Maintaining a server-side session revocation check enforced by resource endpoints.
• Tracking a per-user session_version or token_version value and validating it on every authenticated request.
• Requiring re-authentication before allowing high-risk actions such as email address changes.

Disclosure

I contacted the security team providing a short PoC. The issue was quickly investigated, and ultimately classified as accepted risk with compensating controls in place.

Timeline