Unauthenticated Profile API Allows Account Takeover Across a Retail Group

The Vulnerability

The retail group operates a shared sign-in service used by its shopping, cinema, and leisure brands. Its progressive-profiling service, the component that fills in customer profile details, exposed an endpoint that performed no authentication and no ownership check on either reads or writes.

The endpoint sat behind the identity provider and acted as a thin proxy to the underlying account management. A read request returned a user's full profile. A write request set fields on the underlying root account, including the login email and password. Neither required a token, a cookie, or a session. The only inputs were a public client identifier visible in any logged-out login redirect, and the victim's internal account identifier.

The one precondition

Every action needs the victim's internal account identifier. This is the single honest precondition that makes the finding High rather than Critical. The identifier is high-entropy, so neighbours of a known value do not exist, and there was no reachable lookup that maps an email, phone, or membership number to the identifier on any surface tested. Blind mass discovery is therefore impractical. An attacker sources a single identifier out of band: a logged token, a stolen token, a leak, or support or CRM data. Given one, the read and takeover are trivial and fully unauthenticated.

The Attack

Unauthenticated data read

From a logged-out browser with no session and no cookies, a request to the profile endpoint carrying only the public client identifier and a victim identifier returned the victim's first name, last name, email, mobile, date of birth, nationality, title, and country. This alone is identity-grade data usable for phishing, SIM-swap, and fraud.

Unauthenticated account takeover

Holding only the identifier, the attacker overwrote the victim's root login credentials. The endpoint rejected changing both the password and the email in one call, so the takeover used two sequential unauthenticated writes, password then email, each writing the captured profile back so the rest of the account looked untouched. Both returned success. The attacker then logged in with the new email and password and had full access to the account: order and booking history, loyalty membership and points, and saved data. Because the login email was now the attacker's, the original owner was locked out and could not self-recover.

Silent, and bypassing the front-end

The takeover wrote the victim's profile back unchanged, so the account still looked complete and the owner received no prompt or signal. The email and mobile that this endpoint changes are fields the account interface does not let a user edit at all, so the endpoint overrode a restriction the product enforces in its own front-end, with no authentication.

The Impact

Proven impact is unauthenticated account takeover of any customer of this shared sign-in service, plus full personal-data disclosure. Because the takeover writes target the underlying root account, the same primitive reaches every brand sitting on the shared identity provider, not just one. The login as the victim was confirmed end-to-end on a researcher-controlled account, and the email change reaching the root account was confirmed by the tenant-wide uniqueness check rejecting an in-use address and accepting a fresh one.

The exposed profile data is regulated personal information. The combination of full identity read and silent credential overwrite, both with no authentication, is exactly what a customer sign-in service must never allow without a caller token and an ownership check.

Remediation

• Require an authenticated caller token on the profile endpoint for both reads and writes. No profile read or credential write should ever succeed from a logged-out request.
• Enforce an ownership check so a caller can only read or modify the account it is authenticated as. The internal identifier must never be sufficient on its own.
• Never allow an unauthenticated path to set a root login email or password. Credential changes must require the current password or a verified out-of-band step.
• Add rate limiting and anomaly detection on the endpoint, and audit for prior unauthenticated reads or writes against accounts the caller did not own.