Better Auth SSO Added Users to the Wrong Organization (2026)

On 11 August 2026 Better Auth published GHSA-8c5h-wx78-2cfg, a CVSS 8.1 advisory against @better-auth/sso. The summary is one sentence: an organization owner could register an SSO provider for a domain they did not own, and users with that email domain got quietly added to their organization.

We pulled both builds off npm and diffed them. The advisory is accurate, and it undersells two things: what triggers the assignment, and how little configuration you needed to be exposed.

The one line that mattered

Here is the provider lookup from @better-auth/sso 1.6.26, taken from the published bundle:

const domain = user.email.split("@")[1];
if (!domain) return;
const whereClause = [{ field: "domain", value: domain }];
if (domainVerification?.enabled) whereClause.push({
  field: "domainVerified",
  value: true
});
let ssoProvider = await ctx.context.adapter.findOne({
  model: "ssoProvider",
  where: whereClause
});

The domainVerified filter is conditional. It is pushed onto the query only when domainVerification.enabled is true, and Better Auth's SSO documentation says that flag "is disabled by default and must be explicitly enabled."

So on a stock configuration the query reduces to "find me any SSO provider whose domain column equals this user's email domain." Nobody checks who put that row there.

It fired on Google sign-in, not just SSO

This is the finding that changed how serious we think this is, and it comes from Better Auth's own code rather than from the advisory.

The function is invoked from an after middleware with this matcher:

after: [{
  matcher(context) {
    return context.path?.startsWith("/callback/") ?? false;
  },
  handler: createAuthMiddleware(async (ctx) => {
    const newSession = ctx.context.newSession;
    if (!newSession?.user) return;
    if (!ctx.context.hasPlugin("organization")) return;
    await assignOrganizationByDomain(ctx, {
      user: newSession.user,
      provisioningOptions: options?.organizationProvisioning,
      domainVerification: options?.domainVerification
    });
  })
}]

/callback/ is Better Auth's social provider callback, not /sso/callback/. The library's own docstring on the function says so in plain language:

This enables domain-based org assignment for non-SSO sign-in methods (e.g., Google OAuth with @acme.com email gets added to Acme's org).

That is a documented feature, not an accident. The bug is that the feature trusted an unverified claim. So the population at risk was never "our SSO users." It was every user who signed in with Google or GitHub while the SSO plugin and the organization plugin were both installed.

You did not have to configure anything

Look at what the handler passes down: provisioningOptions: options?.organizationProvisioning. If you never configured organizationProvisioning, that value is undefined.

Now look at the first guard inside the vulnerable function:

if (provisioningOptions?.disabled) return;
if (!ctx.context.hasPlugin("organization")) return;

const entries = domain.split(",").map((entry) => entry.trim()).filter(Boolean);

The re-read of the canonical user matters more than it looks. The old code trusted the user object handed to it by the session; the new code fetches the row by id before making any decision.

Check yours

npm ls @better-auth/sso

npm install @better-auth/sso@^1.6.27

Sources

Both package builds were downloaded from the npm registry and diffed on 2026-09-10. Every code excerpt above is quoted from the published bundle rather than from the repository, so it is the code that actually shipped.