Summary
The @better-auth/scim plugin contains an authorization bypass where SCIM tokens can reuse provider IDs already assigned to other authentication providers.
Under specific configurations, an authenticated user could mint SCIM tokens that resolve to accounts they did not provision, enabling unauthorized listing, modification, and deletion of global user records.
Affected context
This vulnerability appears in deployments using the @better-auth/scim plugin alongside other identity providers such as SSO, SAML, OIDC, generic OAuth, or social login.
It is relevant when SCIM provisioning is enabled and provider IDs for SCIM are configured within the same logical namespace as other providers.
The risk increases when global user account and profile data are shared across providers and there are no additional uniqueness or ownership checks on SCIM-resolved accounts.
Exploit preconditions
- Attack surface: SCIM HTTP endpoints exposed by the better-auth SCIM integration
- Required access: Ability for an authenticated user to obtain or mint SCIM tokens (e.g., legitimate tenant or delegated admin within the system)
- Trigger point: Issuance of a SCIM token whose provider ID collides with an existing non-SCIM provider namespace (SSO, SAML, OIDC, OAuth, social providers)
- Why exploitation is possible: The SCIM token issuance logic accepted provider IDs already used by other providers and reused the same logical provider identifier for both SCIM configuration and account ownership resolution; as a result, SCIM routes could operate on user rows that the SCIM token owner never provisioned.
Why this happens
The core issue stems from improper input validation and namespace separation of provider identifiers.
SCIM token issuance failed to reject provider IDs that were already bound to other identity provider types, and the system reused the same logical provider ID both to configure SCIM behavior and to determine which accounts a SCIM token could manage.
This design maps to CWE-20: Improper Input Validation, because the system accepted provider IDs without enforcing uniqueness or isolation constraints, allowing logically invalid combinations that broke authorization boundaries.
Conceptually, this is an authorization-bypass pattern where identity and provisioning scopes are inferred from unvalidated identifiers, rather than from explicit, verified ownership relationships.
Potential impact
- An attacker with SCIM access could list global user accounts they did not provision
- Attackers may read sensitive profile and account metadata tied to other providers
- Existing user records, including email and profile attributes, could be updated or overwritten without uniqueness checks
- Sessions associated with unrelated accounts can be deleted, causing forced logouts or denial of service
- Full account takeover is possible by rewriting identity-related fields or deprovisioning legitimate accounts
- Broad unauthorized deprovisioning of users or groups across tenants or organizations may occur
General mitigation guidance
Effective mitigation focuses on establishing strict separation and validation of provider identifiers and enforcing explicit authorization checks on SCIM operations.
Recommended defensive patterns include:
- Enforce unique provider namespaces for SCIM versus other identity providers, ensuring that a SCIM provider ID cannot collide with SSO, SAML, OIDC, OAuth, or social provider IDs.
- Introduce strict validation at token issuance time, rejecting any SCIM token whose provider ID is not explicitly registered as a SCIM provider and bound to the requesting party.
- Model ownership relationships explicitly: SCIM tokens should be constrained to act only on accounts they provisioned or that are explicitly linked to their tenant or organization.
- Add server-side authorization checks on SCIM routes to verify that every read, update, and delete operation targets accounts within the token's allowed scope, independent of the incoming provider ID.
- Apply defense-in-depth on global fields: enforce uniqueness and conflict checks for global identifiers like email addresses or profile IDs, and disallow arbitrary rewrites from provisioning channels.
- Use least-privilege token design, granting SCIM tokens the minimal set of operations necessary (e.g., create/update within a tenant) and avoiding broad global admin semantics.
How teams detect issues like this
Identification of this class of issue typically relies on both code-level and behavioral analysis.
Potential detection approaches include:
- Static analysis and code review focusing on:
- Flows where provider IDs, tenant IDs, or namespaces are accepted from configuration or user-controlled input without uniqueness checks
- Shared identifiers used for both configuration and authorization decisions
- SCIM routes that lack explicit ownership or tenant-bound checks for each user row they access
- Authorization policy reviews, ensuring that SCIM token scopes are modeled explicitly and that APIs never implicitly trust provider identifiers to define access boundaries.
- Audit logging and anomaly detection:
- Logging all SCIM operations with provider ID, token subject, and target account ID
- Alerting on patterns where a single SCIM token acts across multiple tenants or provider namespaces, or modifies users it did not create.
- Automated tests and security tooling:
- Authorization-focused integration tests that attempt to use SCIM tokens to access accounts from other providers
- Use of API security scanners or custom scripts to probe for cross-tenant or cross-provider access using SCIM endpoints.
