Authorization Bypass Through User-Controlled Key Affecting @better-auth/scim package, versions <1.6.22>=1.7.0-beta.0 <1.7.0-beta.10

@better-auth/scim is a SCIM plugin for Better Auth

Affected versions of this package are vulnerable to Authorization Bypass Through User-Controlled Key via SCIM token issuance and user resolution in the SCIM routes. An authenticated user can act on SCIM-managed accounts owned by another provider namespace by minting or using a SCIM token whose provider ID matches an existing SSO, SAML, OIDC, OAuth, or social provider ID. This lets the attacker list, update, or delete users they do not own, which can lead to account takeover, user deletion, and loss of access for affected users.

Notes

• In the non-organization delete path, the vulnerable behavior removed the entire global user record when the SCIM token’s provider matched, even if that user also had other linked identities. That makes the impact broader in deployments that link SCIM-provisioned accounts to password, social, or SSO logins, because a SCIM deletion could tear down the user’s other access paths too.

• The issue is only reachable where authenticated users are allowed to mint SCIM tokens and where account rows under colliding provider IDs already exist. The maintainer's advisory calls out custom provider IDs for SSO/SAML/OIDC/generic OAuth/social providers as the collision source; default provider IDs without that namespace overlap are not the problematic case.

Workarounds

• Configure canGenerateToken to reject SCIM provider IDs that match any provider namespace already used by your app, including built-in providers, social providers, generic OAuth providers, SSO, SAML, and OIDC; this blocks the provider-id collision used to mint unauthorized SCIM tokens.
• Restrict which authenticated users can generate SCIM tokens; this reduces the chance that a low-privileged user can obtain a token for a colliding provider namespace.
• Audit existing scimProvider rows and remove any row whose providerId matches another account provider namespace; this prevents existing colliding SCIM providers from being used for unauthorized user resolution.
• Do not rely on active: false deprovisioning reports from your identity provider until after upgrading; verify that deactivated users have actually lost access, especially if your IdP signals deprovisioning through SCIM active: false.
• If you use SCIM account linking, avoid broad domain-based linking rules; prefer organization-membership checks or an explicit application predicate so a shared email domain cannot be used to manage a pre-existing user.

• GitHub Commit
• Maintainer's Advisory