Summary
better-auth SCIM improperly associates non-organization SCIM providers with their creators, causing an authorization check failure.
Under these conditions, an authenticated user may manage other users' SCIM providers, including regenerating bearer tokens and authenticating to SCIM APIs with attacker-controlled credentials.
Affected context
This vulnerability arises in deployments using better-auth SCIM versions from 1.5.0 before 1.7.0-beta.4 where SCIM providers are not correctly bound to the creating account by default.
It primarily affects non-organization SCIM providers exposed through authenticated dashboards or management APIs.
Environments where multiple users can manage SCIM configurations and tokens are at higher risk, especially if SCIM endpoints are integrated with provisioning workflows or identity systems.
Exploit preconditions
- Attack surface: Authenticated web or API interfaces used to configure and manage SCIM providers.
- Required access: Valid user account on the affected better-auth deployment; no special administrative role is strictly required if the misbinding applies globally.
- Trigger point: Actions such as viewing, updating, or regenerating SCIM providers or bearer tokens that are not properly tied to the current user.
- Why exploitation is possible: The system does not consistently enforce ownership checks (object-level authorization) for non-organization SCIM providers, allowing one authenticated user to operate on resources belonging to another user.
Why this happens
The underlying issue is a missing or incomplete object-level authorization check, aligning with CWE-639: Authorization Bypass Through User-Controlled Key.
SCIM provider instances are not strictly bound to their creator or owner when accessed, so the authorization layer relies on the presence of an authenticated session without confirming resource ownership.
This design allows users to indirectly reference or manipulate SCIM providers they do not own, leading to unauthorized token management and control over SCIM integration endpoints.
Potential impact
- Attackers could regenerate SCIM bearer tokens for other users' providers.
- Attackers may invalidate legitimate SCIM tokens, disrupting provisioning or deprovisioning flows.
- Attackers can authenticate to SCIM API routes using attacker-controlled tokens, potentially manipulating user or group data.
- Provisioning systems relying on SCIM could be misconfigured or poisoned, leading to unauthorized account creation or modification.
- Audit trails and access control assumptions may be undermined due to cross-user control of SCIM integrations.
General mitigation guidance
Effective mitigation focuses on enforcing strict object-level authorization and reducing the trust placed in user-supplied identifiers.
Common defensive patterns include:
- Ensuring every SCIM provider and token is strongly associated with an owning principal and that all management operations verify this ownership.
- Designing resource access APIs so that identifiers are derived from the authenticated context rather than client input wherever possible.
- Applying least-privilege principles to SCIM management capabilities, limiting which roles can create or modify providers and tokens.
- Introducing centralized authorization policies that consistently enforce ownership checks across all resource types, including non-organization providers.
- Implementing defense-in-depth by logging and alerting on unusual cross-account token operations or SCIM configuration changes.
How teams detect issues like this
Organizations can detect similar issues by:
- Reviewing authorization middleware and controllers for consistent checks that tie SCIM providers and tokens to the authenticated user or appropriate tenant.
- Using static analysis or linting rules to flag controller endpoints that access provider records without explicit ownership or scope validation.
- Conducting targeted code reviews focusing on ID-based lookups (e.g., provider IDs) to ensure they are constrained by the current user's scope.
- Implementing security monitoring that highlights token regeneration events, cross-user access to SCIM resources, and anomalous SCIM API usage patterns.
- Leveraging automated security testing tools or manual penetration testing to attempt cross-account operations on SCIM configuration endpoints.
