Summary
Thirty bees contains an authentication bypass in PasswordController::resolveCustomer() that can allow an unauthenticated attacker to reset a registered customer's password. The issue becomes exploitable when guest checkout is enabled and an attacker can obtain a guest account token associated with the victim's email address.
Thirty bees contains an authentication bypass in PasswordController::resolveCustomer() that can allow an unauthenticated attacker to reset a registered customer's password. The issue becomes exploitable when guest checkout is enabled and an attacker can obtain a guest account token associated with the victim's email address.
Affected context
The vulnerability affects Thirty bees installations through version 1.7.0 when guest checkout is enabled and password-reset handling accepts guest account tokens without adequately confirming ownership of the registered customer account. The vulnerable behavior is associated with the customer resolution and password-reset flow.
The vulnerability affects Thirty bees installations through version 1.7.0 when guest checkout is enabled and password-reset handling accepts guest account tokens without adequately confirming ownership of the registered customer account. The vulnerable behavior is associated with the customer resolution and password-reset flow.
Exploit preconditions
- Attack surface: Customer password-reset functionality - Required access: No authenticated account is required; the attacker must
be able to create or use a guest order associated with the target email
address
- Trigger point: PasswordController::resolveCustomer() while processing a
guest secure key
- Why exploitation is possible: Guest-order credentials can be accepted as
sufficient authority to identify and reset a registered customer's
password
- Attack surface: Customer password-reset functionality - Required access: No authenticated account is required; the attacker must
be able to create or use a guest order associated with the target email
address
- Trigger point: PasswordController::resolveCustomer() while processing a
guest secure key
- Why exploitation is possible: Guest-order credentials can be accepted as
sufficient authority to identify and reset a registered customer's
password
Why this happens
The underlying flaw is an authorization failure caused by treating a guest account token as equivalent to proof of control over a registered customer account. This behavior maps to CWE-639, Authorization Bypass Through User- Controlled Key, because a user-controlled identifier or token can select a protected account without an adequate ownership check. The insecure pattern is the failure to enforce distinct authorization boundaries between guest orders and registered customer password changes.
The underlying flaw is an authorization failure caused by treating a guest account token as equivalent to proof of control over a registered customer account. This behavior maps to CWE-639, Authorization Bypass Through User- Controlled Key, because a user-controlled identifier or token can select a protected account without an adequate ownership check. The insecure pattern is the failure to enforce distinct authorization boundaries between guest orders and registered customer password changes.
Potential impact
- An attacker may reset a victim's account password.
- The attacker could take over the affected customer account.
- Stored personal, order, or address information may be exposed.
- An attacker may misuse account privileges or saved account functionality.
- An attacker may reset a victim's account password.
- The attacker could take over the affected customer account.
- Stored personal, order, or address information may be exposed.
- An attacker may misuse account privileges or saved account functionality.
General mitigation guidance
Mitigation generally focuses on separating guest-order authorization from registered-account recovery. Password-reset workflows should require independent proof of account ownership, use narrowly scoped and single-purpose recovery tokens, and avoid deriving authorization solely from user-controlled email addresses or guest identifiers. Guest checkout and account-recovery policies can be configured to minimize trust overlap, while session invalidation, rate limiting, notification, and least-privilege controls can reduce abuse impact. Security-sensitive actions should be validated server-side before changing account credentials.
Mitigation generally focuses on separating guest-order authorization from registered-account recovery. Password-reset workflows should require independent proof of account ownership, use narrowly scoped and single-purpose recovery tokens, and avoid deriving authorization solely from user-controlled email addresses or guest identifiers. Guest checkout and account-recovery policies can be configured to minimize trust overlap, while session invalidation, rate limiting, notification, and least-privilege controls can reduce abuse impact. Security-sensitive actions should be validated server-side before changing account credentials.
How teams detect issues like this
Detection can include static analysis and code review for password-reset paths that resolve accounts from guest keys, order identifiers, or user-controlled email addresses without an independent authorization check. Runtime monitoring can look for unusual guest-order creation followed by password-reset requests, repeated recovery attempts, and credential changes affecting existing accounts. Policy enforcement may require security review for customer-identity resolution and recovery logic, and automated review tools can help identify authorization checks that are missing or applied after account selection.
Detection can include static analysis and code review for password-reset paths that resolve accounts from guest keys, order identifiers, or user-controlled email addresses without an independent authorization check. Runtime monitoring can look for unusual guest-order creation followed by password-reset requests, repeated recovery attempts, and credential changes affecting existing accounts. Policy enforcement may require security review for customer-identity resolution and recovery logic, and automated review tools can help identify authorization checks that are missing or applied after account selection.
