Logic-Based Privilege Escalation: Exploiting Flawed Business Rules for Unauthorized Role Promotion

Why This Matters

A 2022 bug bounty disclosure against a project management SaaS platform demonstrated a multi-step privilege escalation that bypassed all standard access controls. The researcher registered as a free user, then triggered the "invite a team member" workflow — which sends an invitation email to any address — using their own secondary email address as the target. The invitation was generated with an admin role because the inviting account happened to be an org admin, and the invitation link did not verify that the invited email was not already associated with the inviting account's owner. By accepting the invite from the secondary email and then linking both accounts, the researcher gained admin access to the organisation. No SQL injection, no XSS, no token forgery — pure workflow manipulation. The report earned $8,500 and required a complete redesign of the invitation flow.

Core Concept

Business logic privilege escalation exploits the ordering, combination, or repetition of legitimate application workflows to reach a privilege state that should be unreachable through normal use. Unlike vertical privilege escalation via IDOR or broken access control, this class of vulnerability requires the attacker to complete valid steps — they are authenticated, they are using real features — but in an order or combination the developer did not anticipate.

Common patterns include:

Out-of-order step execution: a multi-step flow (register → verify email → configure role → activate) allows an attacker to call step N before completing step N-1, reaching an intermediate privileged state. For example, triggering the admin invitation step before completing email verification allows the invitation to be issued under unverified credentials.

Account linking abuse: when a platform allows linking a social OAuth account to an existing local account, the privilege level of the resulting merged account may be the higher of the two. An attacker with a low-privilege local account can link a high-privilege OAuth account to inherit its roles.

Invitation token reuse: a single-use invitation token is not invalidated after acceptance, allowing it to be replayed to create additional privileged accounts or transfer the privilege to a different account than intended.

Workflow audit logging — recording every state transition with the authenticated user identity, timestamp, and source IP — is the essential detective control. Enforcement requires server-side step sequencing: the server tracks which steps have been completed for a given session or workflow instance and rejects requests for step N if step N-1 is not recorded as complete.

Technical Deep-Dive

# Step 1: Attacker registers as free user (account A)
POST /api/auth/register HTTP/1.1
Host: app.example.com
Content-Type: application/json

{"email": "[email protected]", "password": "P@ssw0rd1", "plan": "free"}

# Step 2: Attacker is now an org admin (first user in org gets admin by default)
# Trigger admin invitation for own secondary email — before completing billing setup
POST /api/org/invitations HTTP/1.1
Host: app.example.com
Cookie: session=attacker_session
Content-Type: application/json

{"email": "[email protected]", "role": "admin"}

# Server response (vulnerable — does not check that inviter completed setup):
# {"invitation_id": "INV-4421", "token": "tok_abc123", "role": "admin", "expires": "..."}

# Step 3: Accept invitation with secondary account (account B, newly registered)
POST /api/auth/accept-invitation HTTP/1.1
Host: app.example.com
Content-Type: application/json

{"token": "tok_abc123", "email": "[email protected]", "password": "P@ssw0rd2"}

# Account B now has admin role in attacker's org

# Step 4: Replay the invitation token for a third account
POST /api/auth/accept-invitation HTTP/1.1
Host: app.example.com
Content-Type: application/json

{"token": "tok_abc123", "email": "[email protected]", "password": "P@ssw0rd3"}

# Vulnerable server: token not invalidated after first use — third admin account created

# OAuth account linking abuse — link high-privilege OAuth to low-privilege local account
import requests

s = requests.Session()
# Authenticate as low-privilege local account
s.post('https://app.example.com/api/auth/login',
       json={'email': '[email protected]', 'password': 'P@ssw0rd1'})

# Initiate OAuth link flow for a Google account that is an admin in another org
r = s.get('https://app.example.com/api/auth/oauth/google/link')
# Follow OAuth flow with high-privilege Google account
# After link: check effective role
me = s.get('https://app.example.com/api/users/me').json()
print(f"Effective role after link: {me['role']}")  # may show: admin

Security Assessment Methodology

1. Map all multi-step workflows — Enumerate registration, invitation, account linking, role promotion, and billing upgrade flows. Document the expected step sequence and which steps require prior state.
2. Test out-of-order step execution — For each multi-step flow, attempt to execute step N directly (via API) without completing step N-1. Observe whether the server enforces step ordering or merely relies on the UI to prevent out-of-order access.
3. Test invitation token reuse — Accept an invitation once, then replay the same invitation token from a different session or account. Check whether additional accounts are created or whether the privilege transfer repeats.
4. Test account linking with elevated OAuth accounts — Link a high-privilege external account to a low-privilege local account. Check the effective role of the merged account.
5. Test invitation role parameter tampering — If the invitation request includes a role parameter, modify it from member to admin or owner. Observe whether the server accepts the client-supplied role or derives it from the inviter's permissions.
6. Review workflow audit logs — If accessible (admin panel or log export), review whether all privilege-change events are recorded with actor identity. Missing audit entries indicate absent logging controls.

Defensive Countermeasure — Enforce server-side step sequencing by storing completed workflow steps in a server-side state record (database table or cache entry) keyed to the workflow instance ID. Before executing any step, verify that all prerequisite steps are marked complete in this record. Invalidate invitation tokens immediately upon first use by setting a used_at timestamp and rejecting any token with a non-null used_at. Derive invitation roles exclusively from the inviting user's current server-side role — never from client-supplied parameters. Implement workflow audit logging for all privilege-change events with immutable, tamper-evident records.

Common Assessment Errors

• Testing only direct API calls to privileged endpoints — Logic escalation requires following the workflow partially. Test the sequence of calls, not just individual endpoints in isolation.
• Missing invitation token reuse — Invitation systems often treat tokens as read-only lookup keys rather than one-time secrets. Always attempt replay after first acceptance.
• Not testing account linking with accounts from different organisations — Cross-org account linking may merge privilege contexts in unexpected ways. Test with accounts that have different roles in different organisations.
• Assuming role parameters are display-only — If a role field appears in an invitation or registration request body, it may be processed server-side even if the UI does not allow editing it. Always test role parameter tampering.
• Overlooking email alias bypass — [email protected] and [email protected] are typically the same mailbox. If the application treats them as distinct identities, self-referral and multi-account flows become trivial.
• Not checking for step-skip in the billing upgrade flow — Billing upgrade workflows sometimes create admin-level API keys or expand permissions before payment is confirmed. Test the upgrade flow by jumping directly to the post-payment confirmation endpoint.

NICE Framework Alignment

Further Reading

• OWASP Testing Guide v4.2, OTG-BUSLOGIC-009: Test Upload of Unexpected File Types — OWASP Foundation
• Portswigger Web Security Academy: Business Logic Vulnerabilities — PortSwigger
• HackerOne Hacktivity: Multi-Step Privilege Escalation Disclosures — HackerOne Platform (public)