CVE-2026-67330 in better-auth
Summary
by MITRE • 08/01/2026
@better-auth/scim (a better-auth plugin) versions >= 1.4.0-beta.27 through <= 1.6.21 and >= 1.7.0-beta.0 through <= 1.7.0-beta.9 contain an authorization bypass. SCIM token issuance did not reject provider IDs already used by existing SSO, SAML, OIDC, generic OAuth, or social account providers, and the same logical provider ID was used for both SCIM provider configuration and account ownership. An authenticated user could mint a SCIM token whose provider ID collided with an existing provider namespace, causing SCIM user routes to resolve account rows the token never provisioned. This allowed listing, reading, updating (including rewriting global profile/email fields without uniqueness checks), and deleting global user accounts and sessions, resulting in account takeover and unauthorized deprovisioning. Fixed in 1.6.22 and 1.7.0-beta.10 (1.7.0-rc.0).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/01/2026
The vulnerability identified in @better-auth/scim plugin versions between 1.4.0-beta.27 and 1.7.0-beta.9 represents a critical authorization bypass that stems from inadequate provider ID validation during SCIM token issuance processes. This flaw exists within the authentication and authorization framework where the system fails to enforce unique identifier constraints across different provider types including SSO, SAML, OIDC, generic OAuth, and social account providers. The root cause lies in the logical overlap between SCIM provider configuration identifiers and account ownership namespaces, creating a scenario where duplicate provider IDs can be legitimately issued by the system.
The technical implementation of this vulnerability allows authenticated users to exploit a race condition in identifier management by minting SCIM tokens that utilize provider IDs already assigned to existing authentication providers. This collision occurs because the token issuance mechanism does not perform validation checks against existing provider namespaces before granting access permissions. The flaw operates at the intersection of identity management and access control, specifically targeting the SCIM (System for Cross-domain Identity Management) protocol implementation within the authentication framework.
The operational impact of this vulnerability extends far beyond simple unauthorized access, enabling comprehensive account takeover capabilities through multiple attack vectors. An attacker can leverage this bypass to list user accounts, read sensitive profile information, update global fields including email addresses without proper uniqueness validation, and delete both user accounts and active sessions. This multi-faceted exploitation capability directly maps to the attack pattern described in the ATT&CK framework under privilege escalation and account manipulation techniques. The vulnerability essentially allows an authenticated user to assume control over accounts they should not have access to, creating a persistent threat vector for unauthorized data access and system compromise.
The security implications of this authorization bypass align with CWE-285 (Improper Authorization) and CWE-306 (Missing Authentication for Critical Function) classifications, as the system fails to properly verify access permissions before executing sensitive operations. The vulnerability demonstrates poor separation of concerns between different authentication provider types and inadequate input validation mechanisms. Organizations using affected versions face significant risk of data breaches, unauthorized account manipulations, and potential lateral movement within their authentication ecosystems. The fix implemented in versions 1.6.22 and 1.7.0-beta.10 addresses the core issue by introducing proper provider ID validation during token issuance, ensuring that SCIM provider identifiers cannot collide with existing authentication provider namespaces. This remediation aligns with security best practices for identity management systems and follows the principle of least privilege by preventing cross-contamination between different authentication mechanisms within the same platform.