GHSA-J8V8-G9CX-5QF4: Missing Authorization and Access Control Flaw in @better-auth/scim

The @better-auth/scim plugin, part of the better-auth monorepo, provides System for Cross-domain Identity Management (SCIM) integration capabilities. This plugin exposes endpoints to manage directory synchronization, allowing applications to securely provision users and groups. The plugin differentiates between organization-scoped SCIM providers and personal (non-organizational) SCIM providers.

The vulnerability is classified under CWE-862: Missing Authorization and CWE-284: Improper Access Control. When a SCIM provider is configured without an associated organization ID, the endpoints managing token generation fail to validate that the requesting user owns or has permission to modify the provider. This allows any authenticated user within the system to interact with and alter configurations belonging to other tenants or individuals.

The attack surface is accessible via the standard HTTP endpoints registered by the SCIM plugin. Because the token generation endpoint processes requests without checking user-to-provider mappings for personal integrations, unauthorized individuals can overwrite existing providers. The downstream impact of this bypass includes complete account takeovers via administrative SCIM APIs.

The root cause of this vulnerability lies within the authorization middleware helper function assertSCIMProviderAccess defined in packages/scim/src/routes.ts. When a token generation request is submitted to /scim/generate-token, the system checks if a provider with the given providerId already exists. If the provider is found, it calls assertSCIMProviderAccess to verify access permissions.

The check function executes specific logic based on the presence of an organizationId. If the provider is organizational, membership and role checks are performed. However, if the provider is personal (meaning organizationId is empty or undefined), the application attempts to evaluate ownership via the userId field.

In affected versions, the scimProvider table schema does not store or enforce a userId column by default, causing provider.userId to resolve to undefined. When evaluating else if (provider.userId && provider.userId !== userId), the falsy value of provider.userId causes the entire block to be skipped. Consequently, the function returns successfully without throwing an error, indicating the user has authorization when they do not.

In the vulnerable path, the /scim/generate-token handler processes requests with a schema validating providerId and an optional organizationId. The handler then queries the database schema to locate the provider:

const scimProvider = await ctx.context.adapter.findOne<SCIMProvider>({
    model: "scimProvider",
    where: [
        { field: "providerId", value: providerId },
        ...(organizationId
            ? [{ field: "organizationId", value: organizationId }]
            : []),
    ],
});

If the provider is matched, authorization checks are delegated. Below is the vulnerable implementation of assertSCIMProviderAccess in routes.ts prior to the remediation:

async function assertSCIMProviderAccess(
	ctx: GenericEndpointContext,
	userId: string,
	provider: SCIMProvider,
	requiredRole: string[],
): Promise<void> {
	if (provider.organizationId) {
		// ... organization validation logic ...
	} else if (provider.userId && provider.userId !== userId) {
		// Vulnerability: If provider.userId is undefined, this block is bypassed
		throw new APIError("FORBIDDEN", {
			message: "You must be the owner to access this provider",
		});
	}
	// Implicit return (void) results in successful access validation
}

Because the database schema did not require or populate the userId column for personal providers, the variable provider.userId evaluated to undefined. The logic assumed that any personal provider must have a valid userId string assigned to it. Because this was not enforced, the condition failed safe for the attacker rather than failing closed, resulting in complete validation avoidance.

An authenticated attacker with standard permissions can exploit this vulnerability to take over any personal SCIM connection. The attack is performed in several distinct phases, beginning with target discovery and concluding with administrative modification of user accounts.

First, the attacker identifies a target providerId representing an active personal SCIM configuration. They then make a direct POST request to the token generation API using their own authentication credentials:

POST /scim/generate-token HTTP/1.1
Host: vulnerable-app.local
Authorization: Bearer <attacker_session_token>
Content-Type: application/json
 
{
  "providerId": "target-personal-provider-id"
}

The server processes the request, bypasses authorization because provider.userId is absent, deletes the victim's existing SCIM provider record, and creates a new database entry associated with the same providerId. The server then returns a freshly generated administrative token to the attacker.

HTTP/1.1 201 Created
Content-Type: application/json
 
{
  "scimToken": "ZXhhbXBsZXRva2VuOnZpY3RpbS1wcm92aWRlci1pZA=="
}

Armed with this administrative token, the attacker calls the SCIM Users endpoint to modify targeted user metadata, such as replacing a victim's email address with one controlled by the attacker. This allows the attacker to complete an account takeover via standard password-reset or magic-link flows.

The impact of this vulnerability is critical. Successful exploitation leads to a complete breakdown of multi-tenant or multi-user isolation for personal SCIM integrations. The attack allows unprivileged users to disable existing integrations and take control of administrative directory synchronization mechanisms.

Once the attacker generates a valid token, they gain write access to SCIM resources, allowing the arbitrary creation, modification, and deletion of users. The modification of highly privileged users (such as administrators) allows immediate lateral movement and broader system compromise. The attacker can effectively lock legitimate users out of their accounts while establishing persistent administrative access.

This flaw is tracked as GHSA-J8V8-G9CX-5QF4. While no CVE has been assigned to this advisory at the time of writing, the underlying access control failure matches the characteristics of high-severity privilege escalation vectors.

To address this vulnerability, administrators and developers must upgrade @better-auth/scim to version v1.7.0-beta.4 or higher. The patch introduces the providerOwnership security control to properly associate and validate the creating user of a SCIM provider.

Because automating database migrations on live SQL databases can lead to service interruptions, the ownership control is not enabled by default. Developers must explicitly modify their Better Auth configuration to enable ownership tracking and enforce security restrictions:

import { scim } from "@better-auth/scim";
 
export const auth = new BetterAuth({
    plugins: [
        scim({
            providerOwnership: {
                enabled: true
            },
            canGenerateToken: async ({ user, providerId, organizationId }) => {
                // Restrict personal SCIM provider generation to authorized administrators
                if (!organizationId) {
                    return user.role === "super-admin";
                }
                return true;
            }
        })
    ]
});

In addition to the code changes, the database schema must be updated to include the missing userId column on the scimProvider table. The following SQL command performs the required modification:

ALTER TABLE "scimProvider" ADD COLUMN "userId" TEXT;

Applying both the package upgrade and the manual database schema migration ensures that ownership metadata is populated and evaluated correctly during token generation requests.