While testing the team invitation and account registration functionality, I discovered a vulnerability that allowed an attacker to force an arbitrary victim email address to become associated with an attacker-controlled team without the victim's knowledge or consent.

The issue was caused by chaining multiple weaknesses in the invitation and registration flows:

• Invitation tokens were exposed in API responses.
• • Invitation tokens were not sufficiently bound to their intended invitation context.
• • Account registration did not require email ownership verification.
• • The invitation flow did not properly validate ownership of the invited email address.
• • Team membership could be established before the email identity was verified.

By chaining these behaviors, an attacker could pre-register an account using a victim's email address and associate that account with an attacker-controlled team.

When the legitimate owner of the email later performed a password reset, they could access the account and find themselves unexpectedly associated with the attacker's team.

– -

Attack Scenario

The attack can be summarized as follows:

Attacker-controlled Team

→ Send invitation to victim email

→ Invitation token exposed in API response

→ Reuse/replace token in an existing invitation link

→ Register account using victim email

→ No email ownership verification

→ Victim email becomes associated with attacker-controlled Team

→ Legitimate owner performs password reset

→ Victim logs into the account

→ Victim is already a member of the attacker's Team

– -

Step 1 – Attacker-Controlled Team

The attacker first creates or controls a team within the platform.

The attacker then uses the normal team invitation functionality to invite an email address.

For the PoC, a victim-controlled email address was used.

– -

Step 2 – Invitation Token Exposure

When an invitation was sent, the invitation API response contained a sensitive invitation token/code.

The token was subsequently used by the application as part of the invitation validation and activation process.

This exposed token became an important component of the attack chain.

– -

Step 3 – Invitation Token Reuse

I observed that a previously generated invitation link could be used together with another invitation token obtained from the API response.

By replacing the token within the existing invitation link, the invitation flow could be manipulated so that the resulting invitation was associated with the target invitation.

This demonstrated that the invitation token was not sufficiently bound to the intended recipient and invitation context.

– -

Step 4 – Registering an Account Using the Victim's Email

The manipulated invitation could then be used to proceed through the account registration flow.

The application allowed an account to be registered using the victim's email address without requiring the registrant to prove ownership of that email address.

For example:

victim@example.com

No access to the victim's mailbox was required during account creation.

As a result, the attacker could create an account using the victim's email address and associate that account with the attacker-controlled team.

At this point, the victim's email identity had effectively been pre-claimed inside the application.

– -

Step 5 – Victim Email Becomes Unavailable

After the attacker-created account existed, attempting to register another account using the same email address resulted in the application treating the email as already registered.

The legitimate owner of the email therefore could not perform a normal fresh registration using their own email address.

However, because the legitimate owner actually controlled the mailbox, they could still use the password recovery functionality.

– -

Step 6 – Legitimate Owner Performs Password Reset

The legitimate owner later used the normal Forgot Password functionality.

After successfully resetting the password, the legitimate owner was able to log into the account associated with their email address.

The important part was that the account had already been associated with the attacker-controlled team.

The victim had never intentionally accepted an invitation to that team.

– -

Step 7 – Victim Gains Team Membership

After logging into the account, the victim was already associated with the attacker-controlled team.

The membership was not merely displayed incorrectly in the interface.

The victim account was able to interact with the team normally.

During testing, the account was able to perform actions including:

• Removing users.
• • Cancelling invitations.
• • Interacting with team functionality.

This demonstrated that the forced membership resulted in actual functional access to the team.

– -

Impact

An attacker can use this vulnerability to:

• Register accounts using arbitrary victim email addresses.
• • Force victim email identities into attacker-controlled teams.
• • Prevent legitimate users from registering normally because their email is already associated with an account.
• • Cause legitimate users to become associated with organizations they never agreed to join.
• • Break the intended trust relationship between users and organizations.
• • Cause victims to inherit team membership after recovering their account.
• • Allow the victim account to perform team actions according to the permissions associated with the membership.

The primary security impact is on account and team integrity.

The attacker does not need access to the victim's mailbox.

Instead, the attacker manipulates the application's identity and membership state before the legitimate owner interacts with the account.

When the legitimate owner later recovers the account through the normal password-reset flow, the account already contains the attacker-created organizational relationship.

Disclosure

The vulnerability was submitted to the program and subsequently reviewed by the security team.

The report was ultimately determined to be legitimate and rewarded with a $690 bounty.