---
id: "GHSA-mx9r-x6ww-qjw9"
page: "https://infrastack.ai/live/GHSA-mx9r-x6ww-qjw9"
kind: "vulnerability"
aliases: ["GHSA-mx9r-x6ww-qjw9"]
title: "@better-auth/sso: Personal SSO providers can sign in as another provider's users"
severity: "high"
cvss: 8.1
epss: null
exploited: false
status: "open"
category: "package"
products: [{"name": "@better-auth/sso", "fixed": ["1.7.3"], "affected": ">= 1.7.0-rc.2, < 1.7.0", "ecosystem": "npm"}, {"name": "@better-auth/sso", "fixed": ["1.7.3"], "affected": ">= 1.7.0, < 1.7.3", "ecosystem": "npm"}]
ecosystems: ["npm"]
tags: ["better-auth", "cwe-287", "cwe-345", "node", "oidc", "package", "saml", "sso", "typescript"]
not_affected_if: ["resolveuser-configured", "sso-not-used", "version-1.7.3-or-later"]
published_at: "2026-09-29T18:48:44+00:00"
first_seen_at: "2026-11-09T22:53:20+00:00"
updated_at: "2026-11-09T22:59:13+00:00"
sources: [{"source": "ghsa-repo", "url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-mx9r-x6ww-qjw9", "first_seen_at": "2026-11-09T22:53:20+00:00"}]
exploit_sources: []
---

# @better-auth/sso: Personal SSO providers can sign in as another provider's users

Link for people: https://infrastack.ai/live/GHSA-mx9r-x6ww-qjw9 (this .md is for agents)

In affected versions of the @better-auth/sso npm package, a signed-in user can register a personal SSO provider that copies a real provider's issuer and then match accounts linked through that real provider. Better Auth creates a session for the victim's account without victim interaction.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- npm:@better-auth/sso affected >= 1.7.0-rc.2, < 1.7.0 fixed 1.7.3
- npm:@better-auth/sso affected >= 1.7.0, < 1.7.3 fixed 1.7.3

## How to check

- Check the installed version with `npm ls @better-auth/sso`; affected versions are `1.7.0-rc.2` through `1.7.0-rc.6` and `1.7.0` through `1.7.2`.
- Check whether the application sets `resolveUser` in the SSO plugin configuration; without it the exposed path is open.
- Check whether personal SSO provider registration is enabled (default for signed-in users, up to 10 providers each).

## Fix

- `@better-auth/sso` `1.7.3`
- Setting `providersLimit: 0` only stops new registrations and does not remove existing providers.

## Timeline

- 2026-11-09T22:53:20+00:00 ghsa-repo https://github.com/better-auth/better-auth/security/advisories/GHSA-mx9r-x6ww-qjw9

## Documents

- [advisory] Maintainer's advisory: github.com https://github.com/better-auth/better-auth/security/advisories/GHSA-mx9r-x6ww-qjw9

## From the sources

## Am I affected?

You may be affected if you use `@better-auth/sso` `1.7.0-rc.2` through `1.7.0-rc.6` or `1.7.0` through `1.7.2`, and all of these conditions hold:

- An attacker can register a personal SSO provider or use one they registered earlier. Registration is enabled by default for signed-in users, with a limit of 10 providers each.
- Your application has not configured `resolveUser`.
- A victim's account is linked through another OpenID Connect (OIDC) or SAML provider, and the attacker can reproduce that provider's identity and the victim's account identifier.

Configuring `resolveUser` requires an exact provider match and blocks this path. Setting `providersLimit: 0` only stops new registrations; existing providers remain usable.

## Summary

The SSO plugin lets signed-in users register an OIDC or SAML provider. In affected versions, sign-in through a personal provider could match an account linked through a different provider and create a session for that account.

## Impact

An attacker with a Better Auth account can register a provider that copies a real provider's identity and reproduces a victim's user identifier. Better Auth then creates a new session for the victim's account without victim interaction.

The attack does not compromise the real identity provider or steal the victim's existing session.

## Patches

Upgrade `@better-auth/sso` to `1.7.3` or later. The fix prevents one provider from matching an account linked through another provider.

## Workarounds

If you cannot upgrade now, block SSO sign-in at your application boundary until you can install the fixed release.

Setting `providersLimit: 0` prevents new personal-provider registration but does not disable providers that users already registered. If you keep SSO sign-in available, audit existing personal providers and remove any untrusted registrations. If you cannot verify that inventory, registration limits alone are only a partial mitigation.

If you already set `resolveUser`, the affected sign-in path requires an exact provider match. Upgrading is still the recommended fix.

## Technical details

Affected versions found linked accounts by the provider's issuer (the OIDC issuer or SAML entity ID) and the account identifier from the sign-in (the OIDC subject or SAML NameID). The lookup did not also check that the account belonged to the `providerId` that handled the sign-in.

An attacker could register a personal provider with the same OIDC issuer or SAML entity ID as a legitimate provider. The attacker still controlled the new provider's endpoints or signing keys, so it could assert the subject or NameID of an account linked through the legitimate provider. Because the lookup did not enforce the `providerId` boundary, Better Auth treated the victim's account as belonging to the attacker's provider and created a session for the victim. The assertion was valid for the attacker's provider, but it did not prove control of the legitimate provider's account namespace.

Version `1.7.3` restores account lookup using both the registered `providerId` and the asserted account identifier.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_