@better-auth/scim CVE-2026-67330

The application must register the @better-auth/scim plugin and permit authenticated users to generate SCIM tokens (the default canGenerateToken policy is vulnerable). The token-only paths - global email rewrite via PUT/PATCH and account/session deletion via DELETE /scim/v2/Users/:id for a non-organization token - require nothing beyond the SCIM plugin and a valid SCIM bearer token held by a low-privileged authenticated user. The additional cross-namespace account-takeover-by-collision path further requires that SSO, SAML, OIDC, generic OAuth, or social providers exist with custom provider IDs and that account rows already exist under those IDs. Limiting factors: exploitation needs an authenticated account (PR:L, not anonymous), and custom policies that already reject reused provider IDs neutralize the collision vector though not the token-only issues; only the listed version ranges are affected.

The reporter-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N with all vulnerable- and subsequent-system impacts High) scores 9.4 (Critical), consistent with a network-reachable, low-complexity flaw needing only a low-privileged authenticated account. The most severe path - DELETE and email-rewrite against global users - requires only the SCIM plugin plus a valid SCIM token, so AC is genuinely low; the full cross-namespace collision variant additionally depends on pre-existing custom-provider-ID account rows, which raises complexity for that specific sub-path. No EPSS score, KEV listing, POC, or SSVC data was provided, so probabilistic exploitation signals are absent - this is a high-confidence design flaw with detailed public root-cause analysis but no confirmed in-the-wild activity. Net: a real priority for anyone running the SCIM plugin with user-generatable tokens, driven by impact and low barrier rather than by evidence of mass exploitation.

An attacker holding (or self-registering) an ordinary authenticated account on an app using @better-auth/scim mints a SCIM bearer token choosing a provider ID that matches an existing SSO/OIDC provider namespace. Using that token against /scim/v2/Users, they enumerate real users, rewrite a target's email to one they control (bypassing the uniqueness check) for account takeover, or issue DELETE to wipe the victim's user record and sessions. No public POC is currently identified, but the vendor's detailed root-cause description makes the request sequence readily reproducible.