# Provisioning email swap account takeover

SCIM/provisioning sync that lets email change independently of the immutable username or external ID

_Area: Web authentication and account takeover. Seen in 3 disclosed reports; latest 2026-06-24. Updated 2026-11-02._

## How it works
Provisioning systems (SCIM, SSO sync) model a user as attributes that update independently. The identity key should be the immutable username or external ID; email is a mutable attribute. The broken assumption is that email is a safe secondary identity. If a sync accepts a new email for an existing username without validating it against the original identity, an attacker who controls a verified-domain address can rewrite a victim's email, then use ordinary password reset to take the account. The boundary collapses because the system reads "same username, new email" as a legitimate update rather than an identity change.

## Where it shows up
- SCIM/PATCH handlers that update `emails` while leaving `userName`/`externalId` untouched.
- Provisioning connectors that match users by email rather than by immutable ID.
- Email changes that skip re-verification or user notification.
- Default/demo accounts present in every new org or sandbox.

## How to review
Check the invariant: an existing account's email may only change through a path that proves control of the new address, is tied to the immutable identity, and notifies the user. Concretely:
- Does the sync match on username/externalId, and reject an email change that isn't independently verified?
- Can a request keep username fixed and swap only email to mutate an existing account?
- Are demo/default accounts excluded from provisioning?

## How finders spotted it
- Tried importing users with mismatched domains; failures and new-user creation revealed username and email are handled separately, so keeping username and swapping email mutated the existing account instead of creating a new one [E1](https://bugbountylibrary.com/r/h1%3A3178999.md).

## Variants seen
- SCIM email swap on an existing account, then password reset, escalating to default demo accounts present in every org [E1](https://bugbountylibrary.com/r/h1%3A3178999.md).

## Impact and severity
Full account takeover of existing users [E1](https://bugbountylibrary.com/r/h1%3A3178999.md). Impact scaled with default demo accounts (demo-triager, demo-member) present in every new org/sandbox, letting one flaw reach many organizations [E1](https://bugbountylibrary.com/r/h1%3A3178999.md). Severity rose with how widely default accounts are provisioned and with chaining into password reset.

## Seen in open source
Packages and projects where this pattern was found. If the target runs one, compare the version it runs with the fix.
- **GitLab**: Full access to internal Gitlab instances at redash.gitlab.com, dashboards.gitlab.com, prometheus.gitlab.com. Report: https://bugbountylibrary.com/r/h1%3A498964.md

## Evidence
- E1: https://bugbountylibrary.com/r/h1%3A3178999.md
- E2: https://bugbountylibrary.com/r/h1%3A498964.md
- E3: https://bugbountylibrary.com/r/blog%3Abishopfox-com-blog-ai-finds-vulnerabilities-security-experts-find-impact.md