# Invite acceptance skips account state check

Invite accept/convert endpoints granting roles or binding accounts without verifying invite ownership or account type

_Area: Web access control and IDOR. Seen in 3 disclosed reports; 2 confirmed bounties: $5,000 and $20,000; latest 2020-12-03. Updated 2026-10-24._

## How it works
An invite or account-conversion endpoint assumes the caller is the legitimate invitee and that the target account is in the expected state. When that assumption is unverified, the endpoint grants a role or binds an account based on an identifier (invite ID, email, invite key) the caller controls or can observe, rather than on proof of ownership. The role change or binding happens even when validation later fails.

## Where it shows up
- Accept-invite / accept-invitation APIs that take an invite ID or key as the only input.
- Endpoints that return an error but still mutate state (role granted before validation).
- Auto-convert / auto-accept logic that looks up an "existing account" by email without checking its type or status.
- List or management endpoints that return invite keys or acceptance links to the inviter.
- Project/tenant IDs exposed in public page source that feed into invite calls.

## How to review
Check the invariant: the caller must prove they are the intended invitee, and the target account must be in the expected state before any role or binding is applied. Specifically:
- Does accept-invite verify the invite belongs to the requesting user and the stated project/tenant?
- On error paths, is state committed before validation completes? Re-check state after any error response.
- Does conversion verify the existing account's type/status, not just its email?
- Are invite keys or links ever returned to anyone other than the invitee?

## Variants seen
- Accept-invite accepted an invite ID without ownership check, granting admin despite an error response [E1](https://bugbountylibrary.com/r/h1%3A152067.md).
- Auto-conversion of an existing account to collaborator without verifying account type, exploitable via duplicate emails [E2](https://bugbountylibrary.com/r/h1%3A270981.md).
- Invites list endpoint leaked invite_key and acceptance link to the inviter, enabling acceptance on the invitee's behalf [E3](https://bugbountylibrary.com/r/h1%3A1040047.md).

## Impact and severity
Led to admin role escalation and stored XSS against a developer portal [E1](https://bugbountylibrary.com/r/h1%3A152067.md), full access to arbitrary stores [E2](https://bugbountylibrary.com/r/h1%3A270981.md), and email-verification bypass enabling account creation for unregistered emails [E3](https://bugbountylibrary.com/r/h1%3A1040047.md). Severity is high where the granted role is privileged or cross-tenant; worse when identifiers are publicly exposed or errors mask the committed change.

## Evidence
- E1: https://bugbountylibrary.com/r/h1%3A152067.md
- E2: https://bugbountylibrary.com/r/h1%3A270981.md
- E3: https://bugbountylibrary.com/r/h1%3A1040047.md