@better-auth/scim SCIM Token Provider ID Collision Authorization Bypass

Technical Analysis

CVE-2026-67330 stems from a namespace collision flaw where SCIM token issuance failed to validate that a chosen provider ID was not already bound to an existing SSO, SAML, OIDC, generic OAuth, or social provider. Because SCIM provider configuration and account-ownership records share the same logical provider ID field without uniqueness enforcement, an authenticated attacker can register a SCIM token under a colliding ID, causing SCIM user routes to resolve arbitrary existing account rows rather than the token's own scope. This grants unauthorized listing, reading, updating (including bypassing email/profile uniqueness constraints), and deletion of global user accounts and sessions—amounting to account takeover and forced deprovisioning at the identity-provider level. The flaw affects versions >=1.4.0-beta.27 through <=1.6.21 and the 1.7.0-beta.0 through beta.9 line, fixed in 1.6.22 and 1.7.0-rc.0. Organizations running AI agent platforms that use better-auth/SCIM for workforce identity and provisioning of agent-service accounts or API-key-bearing users are directly exposed: an attacker could hijack or deprovision agent-associated identities, exfiltrate credentials tied to those accounts, or disrupt agent orchestration by deleting sessions/accounts used for automated tool access.

Affected Systems

@better-auth/scim npm package versions >=1.4.0-beta.27 through <=1.6.21, and >=1.7.0-beta.0 through <=1.7.0-beta.9; any better-auth deployment integrating SCIM provisioning alongside SSO/SAML/OIDC/generic OAuth/social login providers.

Indicators of Compromise

• No specific file hashes, IPs, or domains published; indicators are behavioral - unexpected SCIM token creation events, SCIM API calls modifying/deleting accounts outside expected provider scope, provider ID collisions in auth logs, unauthorized profile/email field changes via SCIM endpoints.

Remediation Steps

1. 1

   Upgrade immediately

   Update @better-auth/scim to version 1.6.22 or 1.7.0-rc.0 (1.7.0-beta.10) or later, which enforces provider ID uniqueness across SCIM and SSO/OAuth namespaces.

2. 2

   Audit existing SCIM tokens

   Review all issued SCIM tokens and provider ID mappings for collisions with existing SSO/SAML/OIDC/OAuth/social provider IDs; revoke and reissue any suspicious tokens.

3. 3

   Review account and session logs

   Check for anomalous account modifications, email/profile changes, or deletions performed via SCIM routes that do not correspond to legitimate provisioning activity.

4. 4

   Rotate credentials for affected accounts

   Force password resets, session invalidation, and API key rotation for any accounts identified as potentially compromised, including service/agent accounts.

5. 5

   Enforce namespace isolation

   Where possible, implement additional application-layer checks ensuring SCIM provider configuration cannot reference or collide with existing identity provider namespaces.