How I Stumbled Upon a Critical Webshop Vulnerability (and How It Vanished Without a Trace)

Originally published on Medium

Overview

Vulnerability	Deterministic password reset / account takeover
Class	CWE-640 (Weak Password Recovery Mechanism for Forgotten Password)
Preconditions	Attacker knows or guesses a customer email address
Impact	Account takeover for affected webshop accounts
Status	Fixed silently by the operator after disclosure attempts

TL;DR

The reset flow generated a new password from the email local-part, uppercased it, and applied it immediately. There was no reset token, no proof that the requester controlled the mailbox, and no random secret. For alice@example.com, the new password became ALICE.

Root Cause

Password recovery was implemented as deterministic password replacement instead of token-based account recovery:

input email: alice@example.com
derived password: ALICE
server action: replace account password immediately

The failure is not only weak randomness. The design also lets an unauthenticated requester change the account credential before the legitimate user confirms the reset.

Reset email evidence with the deterministic password pattern redacted to the safe example used in this writeup.

Exploit Flow

1. Identify a customer email address.
2. Submit the email address to the password reset form.
3. Derive the new password locally from the public email prefix.
4. Log in before the victim notices the reset email.

No phishing, race against a reset token, or mailbox access is required.

Impact

• Full account takeover for known customer email addresses.
• Exposure of personal data, order history, invoices, addresses, and any stored payment-adjacent metadata visible in the account.
• Potential lockout of legitimate users because the password is changed by the attacker's reset request.

I originally treated this as critical because exploitation is unauthenticated, simple, and affects the core identity boundary. Exact CVSS depends on the webshop's stored data and transaction capabilities, so this public version avoids overstating a vendor-specific score.

Remediation

• Generate high-entropy, single-use reset tokens server-side.
• Do not change the password until the user proves mailbox control by presenting the token.
• Expire reset tokens quickly and bind them to the account and purpose.
• Invalidate active sessions after successful password change.
• Log and rate-limit reset attempts per account, IP, and subnet.

Disclosure

The issue was reported to the operator's data protection contact with reproduction steps and remediation guidance. After no meaningful response, the issue was escalated to the regional data protection authority. The vulnerable behavior later disappeared without public advisory or direct researcher follow-up.