ThinkBug

About this issue

This report documents a critical account takeover vulnerability caused by inconsistent email handling across application layers.

The issue originates from differences in how the database layer and the SMTP server process and normalize email addresses — specifically due to improper handling of Unicode / Punycode characters.

Because of this mismatch, an attacker can receive password reset tokens intended for a victim without any user interaction.

Technical Overview

Victim's email address:

test@gmail.com

The attacker submits a password reset request using:

test@gmaíl.com

The only difference is a single Unicode character: í.

At the database level, í is normalized and treated as a regular i, so both addresses are considered identical:

gmail.com == gmaíl.com

The user existence check passes. However, the SMTP server sends the reset email exactly as provided — without normalization. The link is delivered to test@gmaíl.com, a domain the attacker controls.

Result

The attacker receives the password reset token and gains full unauthorized access to the victim's account.

• No phishing
• No clicks
• No user interaction

A true Zero‑Click Account Takeover caused by improper email normalization.

Why This Happens

While the database normalizes Unicode and treats characters as ASCII equivalents, the SMTP layer preserves the original attacker-supplied input — resulting in token delivery to an attacker-controlled address.

About this issue

This report describes a logic flaw in social login implementations where email ownership is not strictly enforced during the authentication and registration flow. The issue allows an attacker to take over user accounts by abusing the email confirmation process after social authentication.

The report is public and organized based on multiple independent security research findings that highlight the same root cause across different platforms.

During analysis, it was observed that the application allows users to authenticate using a social login provider (Facebook is used here as an example). However, the application does not immediately verify ownership of the email address associated with the social account.

As a result, the platform may prompt the user to manually enter an email address after social login. This email is trusted and later used to bind the account without enforcing prior ownership verification, creating a critical account takeover scenario.

Steps to Reproduce

1. The victim signs up for an account but does not complete email confirmation.
2. The attacker logs in using a social login provider (Facebook) while removing or limiting the email permission scope.
3. The application asks the attacker to manually provide an email address.
4. The attacker enters the victim's email address.
5. The application sends an email confirmation link to the victim.
6. The victim clicks the confirmation link, unknowingly verifying the attacker's session.

Result

The attacker gains full unauthorized access to the victim's account.

Impact

• Full account takeover
• Unauthorized access to personal data
• Abuse of account‑linked features
• Potential financial and privacy impact depending on application functionality

About this issue

This report describes a critical authentication and account linking flaw in Single Sign-On (SSO) implementations across multiple domains. The vulnerability arises from improper email synchronization between the main application and its subdomains, allowing attackers to hijack user accounts through a seemingly legitimate email change operation.

This report is public and organized based on observations shared by multiple independent security researchers, highlighting a recurring design issue rather than an isolated implementation mistake.

During security testing, it was observed that users could authenticate on various subdomains using their main domain account via SSO. However, the subdomains allowed users to modify their email address independently from the main application.

This behavior raised an important question: what happens if an email address is changed on a subdomain while the main application still treats the original email as authoritative?

The answer resulted in a full account takeover scenario.

Attack Scenario

While logged in through SSO, an attacker can change the email address on a subdomain without triggering any synchronization or validation on the main domain. The main application continues to treat the old email as unused or available.

The attacker can then register a new account on the main application using the victim's updated email address, effectively claiming ownership of the victim's identity.

Once the attacker authenticates back into the subdomain via SSO, the system links the session to the newly created account, granting full access.

Steps to Reproduce

1. Sign up for an account on [REDACTED].com.
2. Log in to sellerevents.[REDACTED].com via SSO.
3. Navigate to /accounts/edit and change the email address associated with the account.
4. Register a new account on [REDACTED].com using the victim's email address that was set on the subdomain.
5. Return to sellerevents.[REDACTED].com and log in.

Result

The attacker gains unauthorized access to the victim's account.

Impact

• Full account takeover
• Access to private user data
• Abuse of account-specific functionality
• Potential privilege escalation depending on user role

About this issue

This blog post documents a logic flaw that allows unauthorized access to guest orders due to improper account‑to‑order binding. The website allows users to place orders as a guest and requires an email address during checkout for shipping and communication. When an attacker later registers an account using the same email address, previously placed guest orders become accessible to the newly created account.

Steps to Reproduce

1. A user places an order as a guest.
2. During checkout the user provides their email address for shipping communication.
3. The order completes and is stored as a guest order.
4. An attacker registers a new account using the same email address.
5. The attacker logs into the newly created account.
6. Previous guest orders associated with that email become visible to the attacker.
7. The attacker can cancel or modify those orders.

Result

Unauthorized access to guest orders, allowing an attacker to:

• View previous guest orders
• Cancel orders
• Modify order details

This results in a Guest Order Takeover due to improper binding between guest orders and later-registered accounts.

Mitigations

• Do not automatically link guest orders to newly registered accounts based solely on email. Require in-band verification (e.g., confirmation link) before associating guest data with an account.
• Apply additional checks (order tokens, one-time codes) before exposing guest order operations to an account.
• Audit and log account-to-order association events and alert on suspicious mass associations.

About this issue

An unusual CSRF technique discovered on a car-related website. The application builds a vehicle-selection URL that appears to be a harmless search listing — but visiting that URL silently adds a vehicle to the logged-in account.

What was observed

When adding a vehicle the site generates a URL like:

https://www.test.com/b/Car-Truck-Secondary-Air-Smog-Pumps/33610/bn_583467?
maspect=contextType:CAR_AND_TRUCK&Submodel=45K&Year=2025&
Engine%20-%20Liter_Display=14.9L&Trim=45K%20Motorhome%20-%20Class%20A&
Model=American%20Eagle&Make=American%20Coach

The page redirects to compatible products — making the request look like a normal search — but simultaneously adds the selected vehicle to account state.

Steps to Reproduce

1. Log in to an account.
2. Add a vehicle by selecting make, model, year, engine and other details.
3. Observe the application redirects to a products URL with vehicle parameters.
4. Copy the generated URL.
5. Log in to a different account (victim).
6. Paste and visit the copied URL while authenticated as the victim.
7. The vehicle is silently added to the victim's account.

Why This Happens

The application performs sensitive actions based on GET request parameters and lacks CSRF protections or explicit user confirmation. Because the URL resembles a harmless search, it bypasses common CSRF assumptions.

Mitigations

• Never perform state-changing actions via GET. Use POST with anti-CSRF tokens.
• Require explicit user confirmation for actions that modify account state.
• Enforce same-site cookie protections for authenticated requests.

About this issue

This report is public and organized from security research observations. It highlights an access control flaw where draft store policies could be exposed to unauthorized users. While reviewing the Preview feature, it was noticed that the application appends a draft=true parameter to preview unpublished content. Further testing revealed that this parameter could be reused on public store URLs, allowing disclosure of non-public draft privacy policies. The core issue lies in trusting an internal preview parameter without enforcing proper authorization checks before rendering draft-level content.

Steps to Reproduce

1. Store owner creates or edits store policies and saves as Draft.
2. The Preview feature reveals the draft=true parameter in the URL.
3. Attacker copies the public store URL and appends: ?draft=true&_tab=about
4. The page loads draft store policies that were never published.

Result

Unauthorized users could view draft store policies, including draft privacy policies intended to remain private until review.

About this issue

This report is public and based on a security vulnerability discovered by Hossam Hamada (LinkedIn Profile) during participation in a bug bounty program. While analyzing a subdomain that was initially out of scope, it was discovered that the backend logic for creating user entities relied solely on the email address to determine if a user already existed. This behavior led to unintended disclosure of sensitive user information when an existing email was reused.

Steps to Reproduce

1. Hossam registered a new account on the platform.
2. After logging in, he started a new application and filled in all required fields.
3. In the optional Owner section, he submitted the following information:
   • Email address
   • First name
   • Last name
   • Phone number
4. The backend processed the request and returned a new user ID since the email was not previously used.

First Request Example:

Request:

{
  "email": "test1@test.test",
  "firstname": "Test1",
  "lastname": "User1",
  "phone": "9018011234"
}

Response:

{
  "id": 12345,
  "email": "test1@test.test",
  "firstname": "Test1",
  "lastname": "User1",
  "phone": "9018011234"
}

5. Hossam then resent the same request but changed all fields except the email address.
6. The backend returned the same existing user data, ignoring the updated fields.

Modified Request Example (Name and Phone Changed):

Request:

{
  "email": "test1@test.test",
  "firstname": "Test2",
  "lastname": "User2",
  "phone": "9018011111"
}

Response:

{
  "id": 12345,
  "email": "test1@test.test",
  "firstname": "Test1",
  "lastname": "User1",
  "phone": "9018011234"
}

7. Finally, when a different email was submitted, a new user ID was generated, confirming that the system only used the email to identify users.

Impact

• Exposure of Personally Identifiable Information (PII)
• Ability to enumerate users via email
• Leakage of sensitive data including full name, phone number, and internal profile attributes

This meant that an attacker could use known email addresses to retrieve full details of existing users without authentication.