All case studies
criticalCVSS 9.1

Signup form that reset anyone's password.

Re-registering an existing user's email allowed an attacker to take over the account.

AuthenticationAPI
Timeline
  1. Discovered (complete)
  2. Proven (complete)
  3. Fixed (complete)
  4. Retested (complete)

What they were shipping

A production web application with email-and-password sign-up.

What we found

The registration endpoint did not reject an email address that already belonged to an account. Instead of refusing the request, it merged the new registration into the existing account, replacing the password with the one the attacker supplied.

How we proved it

We registered against an email address that already had an account and captured the request and response. The server answered 200 OK and reported that the existing account had been merged.

POST /api/auth/register
Host: [redacted]

{
  "email": "founder@[redacted].com",
  "password": "[redacted]"
}

HTTP/1.1 200 OK

"notice": "existing account merged"

Sanitised evidence. Identifying values are redacted.

Business impact

An unauthenticated attacker who knew a user's email address could take over that account, with no access to the victim's inbox and no interaction from the victim.

Fix

Registration now rejects duplicate account ownership conflicts.

Retest

Original exploit replayed after the fix. Fix verified.

Your application keeps changing.
Your security should keep testing.

Put your application into the Zentinel loop.

Start protecting my application

Authorized testing only. All testing occurs within agreed scope and rules of engagement.