CVE-2026-67330: better-auth SCIM Plugin Authorization Bypass via Provider-ID Collision
The @better-auth/scim plugin contains an authorization bypass: SCIM token issuance did not reject provider IDs already used by other identity providers, so an authenticated user could make SCIM routes operate on accounts the token never provisioned. The record describes this as enabling account takeover and unauthorized deprovisioning, with a CVSS base score of 9.9 from the CNA, and fixed versions are named in the description. No confirmed exploitation appears in the sources consulted.
Overview
The @better-auth/scim plugin for better-auth has an authorization bypass tied to provider ID handling. The record states that SCIM token issuance did not reject provider IDs already used by SSO, SAML, OIDC, generic OAuth or social account providers, and that the same logical provider ID served both SCIM provider configuration and account ownership. Details are in the vendor advisory.
Impact
The record describes an authenticated user being able to mint a SCIM token whose provider ID collides with an existing provider namespace. SCIM user routes would then resolve global account rows that the token never provisioned. According to the record, this allows listing, reading, updating and deleting global user accounts and sessions, including rewriting global profile and email fields without uniqueness checks. The stated outcomes are account takeover and unauthorized deprovisioning.
Affected products and versions
- from 1.4.0-beta.27 up to and including 1.6.21
- from 1.7.0-beta.0 up to and including 1.7.0-beta.9
The record's structured affected field lists the same ranges as starting points, so administrators should confirm the installed plugin version against these bounds.
Exploitation status
The KEV catalog entry for this CVE is not listed in the record. No confirmed exploitation in the wild appears in the sources consulted. The SSVC fields in the record report exploitation as none and automatable as no.
Remediation and mitigation
- Upgrade @better-auth/scim to 1.6.22 on the 1.6 line, or to 1.7.0-beta.10 or 1.7.0-rc.0 on the 1.7 line, as stated in the record's description.
- Review which authenticated users can issue SCIM tokens and restrict that capability until the upgrade is applied.
- Revoke SCIM tokens whose provider IDs match names used by other identity providers in your deployment.
Detection guidance
- Audit SCIM token issuance records for provider IDs that also correspond to SSO, SAML, OIDC, OAuth or social providers.
- Look for unexpected changes to user profile or email fields, unexpected session revocations and unexpected account deletions, especially if they correlate with SCIM activity.
- Compare current account and session data against backups or known-good state to identify rows changed outside normal provisioning.
Limitations of the available information
The record does not list fixed versions in its structured fixes field, although the description names 1.6.22, 1.7.0-beta.10 and 1.7.0-rc.0. The CWE assigned is improper input validation, while the description characterizes the flaw as an authorization bypass. Exploit prerequisites beyond authentication, such as required configuration, are not described in the record.
Frequently asked questions
What is the core problem in CVE-2026-67330?
SCIM token issuance did not reject provider IDs already used by other identity providers, so SCIM routes could act on accounts the token never provisioned.
Which versions are affected according to the record?
The record lists from 1.4.0-beta.27 up to and including 1.6.21, and from 1.7.0-beta.0 up to and including 1.7.0-beta.9.
Is this vulnerability known to be exploited in the wild?
The record does not list it in KEV, and no confirmed exploitation appears in the sources consulted.
This analysis was drafted with AI assistance from verified source data and automatically checked against it.