How to review invitation flows for privilege escalation

Treat an invitation as a request to create a particular account membership, not as a portable permission. Review who may issue it, which account and role it proposes, how the invitee is identified, what happens at acceptance, and whether later changes invalidate it. The server should decide the final grant from current policy and an approved invitation record; a URL token or browser form must not choose a stronger role. The answer changes if your app supports automatic group provisioning or SSO: those paths must meet the same account binding and role limits, even though the user may never see an ordinary invitation email. OWASP recommends deny-by-default and permission checks on every request; invitation creation and acceptance are both authorization events.

This checklist produces evidence for a specific privilege-escalation claim. It does not imply that possession of a leaked link proves an account takeover or that source review alone demonstrates a successful exploit.

Illustrative case: a member invitation becomes an admin grant

Illustrative case, not a customer finding: Meridian Cloud lets a billing owner invite teammates. The UI offers “analyst” and “billing editor.” The create API accepts {accountId, email, role}. An old API client also accepts role=technical_admin, a role that the billing owner is not allowed to grant. A pending invitation email contains a token. The acceptance handler retrieves the invitation and creates membership using role from the acceptance request rather than the stored, approved role.

The alarming line is the request-to-role assignment. Before calling it exploitable, trace the full path: perhaps a server-side capability allowlist rejects the role, perhaps a technical approval is required later, or perhaps the membership stays pending. Name each possible control and inspect it. The business consequence, if every later gate is absent, is that an invited ordinary user could gain technical access intended only for a separately approved steward.

The reviewer should write the intended rule first: “A Meridian billing owner may issue only an analyst or billing-editor invitation for Meridian. Acceptance can activate no role beyond the role stored in an approved, unexpired invitation. Technical administration requires a separate technical approver and qualifying MFA.” That last sentence is Meridian's illustrative policy, not an OWASP universal role catalog. OWASP's MFA guidance supports extra protection for sensitive changes, including factor changes; the specific approval structure remains the product team's decision.

Use one checklist for creation and redemption

Work from the deployed route map and schema, not just the email template. Fill this table with actual evidence at a pinned revision:

OWASP's Forgot Password Cheat Sheet describes high-entropy, expiring, single-use tokens for a different sensitive email-link flow. Apply those token properties to invitations as an engineering pattern, while recognizing that an invite also needs account, role and recipient authorization that a password-reset token does not establish.

Compare three sources of the proposed role

In Meridian's synthetic invitation, the persisted record and the request disagree:

stored invitation I-8:
  account=Meridian, recipient=bound invitee, role=analyst
  inviter=BillingOwner7, status=pending, version=3
  expires=2026-10-20T12:00Z

redemption request:
  token=<secret omitted>, role=technical_admin, account=OtherAccount

current policy:
  BillingOwner7 may grant analyst or billing_editor in Meridian

The client fields do not amend the invitation. Reject conflicting fields or omit them from the acceptance schema; never choose the more permissive value. The final grant derives from the approved stored intent and current policy, after authenticating the intended recipient and completing required assurance.

Now change the current state: BillingOwner7 was demoted after issuing I-8. Meridian's chosen policy invalidates pending invitations from an issuer who no longer has invite authority. The redemption must therefore fail even though the token is valid and the original invitation was approved. Another product could use a durable organizational approval independent of the inviter; it must specify that policy and its revocation authority. A signature on the old invitation does not decide between these models.

Make redemption one state transition

Two browser tabs redeem I-8 concurrently. Both can validate the token before either commits. A separate “mark used” call after membership creation can therefore create inconsistent grants or duplicate side effects.

The illustrative commit protocol is:

begin guarded membership operation
  require invitation I-8 is pending, unexpired and version3
  require recipient binding matches authenticated identity
  require current account/grant approval still permits stored role
  require required MFA/enrollment state is complete
  create or reconcile the exact membership under its uniqueness rule
  if membership already exists, do not overwrite its role or reactivate removal
  consume I-8 with that membership identity as its result
commit

The database-specific transaction and locking design is intentionally not supplied. The requirements are atomic consumption with membership outcome, a uniqueness rule for the intended account/identity membership, and a defined relationship to concurrent policy changes. An existing membership needs an explicit grant-change operation; “reconcile” must not mean replace an administrator role with analyst, add privilege, or undo removal as a side effect of accepting an old invite. Checking the inviter before a long pause and then committing without a fence does not satisfy a policy that requires current authority at commit.

For a retry by the same authenticated recipient, return the recorded membership outcome only after current authorization checks; do not create a new membership. For a different recipient or changed role, deny. If that member was subsequently removed, replaying I-8 must not reactivate them. A successful historical redemption is history, not reusable provisioning authority.

All rows are expected synthetic outcomes, not tests performed. Inspect post-accept welcome data and token issuance too: a pending enrollment record must not accidentally return protected reports before the activation boundary. OWASP's authorization guidance supports checking these operations server-side; its reset-token guidance provides related token-lifecycle properties, while invitation-specific role and recipient policy remains the application's responsibility.

Record a defensible outcome

Meridian scope: invite creation and redemption, release M-31. Candidate: acceptance request supplies technical_admin while stored invitation says analyst. Source evidence: acceptance handler appears to use the request field. Unknown: whether membership creation checks the technical approval ledger and role allowlist. Potential effect: invited user receives technical report or administration rights. Status: investigation until that final gate is reviewed. Owner: accounts service engineer. Next evidence: bound membership mutation and an authorized synthetic redemption showing which role was actually committed.

If the downstream mutator enforces the stored approved role, reject this precise escalation path and retain the counterevidence. If it does not, an independent reviewer should validate the actor-to-grant path before publication and help the owner close it. If the invitation state cannot be recovered or the mail provider has rewritten links, mark the token-lifecycle portion unverified. Do not infer safety from one expired link.

Review changes to a pending invitation

An invitation may remain pending while administrators edit roles, change account policy, or correct a recipient address. Meridian should decide which of those changes invalidate the existing token and which create a new version of the same invitation. The security requirement is that redemption cannot combine an old approval with a new, more powerful grant that nobody authorized.

For I-8, changing the recipient or upgrading analyst to technical administrator should require the corresponding current authority. The implementation should not let an ordinary invitation editor make that change merely because they can resend the email. A resend is a delivery operation; a role change is a grant operation. Give them distinct permission checks even if the UI presents them near each other.

Suppose I-8 is reissued as version4 after a legitimate correction. The redemption path must define what an old version3 link does. It might reject it and direct the intended recipient to the latest invitation through a safe flow. It should not silently let the older link activate the newly expanded role. That would make possession of a previously issued token more powerful than the approval it originally represented.

Avoid privilege changes hidden inside acceptance

An existing Meridian member may accept an invitation intended for another role. The earlier protocol deliberately refuses to overwrite the current membership automatically. Make the resulting user experience explicit. It can explain that membership already exists and route any proposed role change to the authorized grant workflow. It should not downgrade an administrator, add technical access, or reactivate a removed membership as an incidental effect of token redemption.

This also helps with multiple pending invitations. If two authorized inviters issue different roles for the same recipient, decide how those requests are reconciled before implementation. “Use the most privileged role” and “last write wins” are business policies with security consequences, not neutral database conveniences. Meridian can instead require an explicit current decision for the final grant.

Inspect side effects after the guarded commit. A welcome email, a default repository assignment, or an automatically generated API credential can expose authority beyond the membership row itself. The review should establish which committed membership and capabilities those effects use. If a retry sends another welcome message, that is not automatically a privilege flaw; if it creates a new broad credential, it is a materially different outcome to investigate.

The final acceptance evidence should therefore include the membership state and the first protected action, not only a successful token response. For this synthetic case, the expected result is analyst access in Meridian with no technical-administrator rights and no access to the substituted account. If enrollment remains pending, the first protected response should respect that pending state. This connects the invitation lifecycle to the authority the invitee actually receives.

Take one privileged invitation through the nine checklist rows and make the stored grant the source of truth. Then examine why an email domain is not membership and how removal should revoke sessions.