Skip to content

v0.1.1 — Auth Dependency Advisories & SCIM Ownership

Choose a tag to compare

@msywulak msywulak released this 28 Jul 11:25
· 382 commits to main since this release

Security patch closing all four Better Auth advisories surfaced by the container-image scanning added in #4822. Three close with the upgrade to 1.6.25 (#4863); the fourth needed a code fix (#4864).

GHSA-j8v8-g9cx-5qf4 — SCIM provider ownership

@better-auth/scim does not bind non-organization ("personal") SCIM providers to their creator. The plugin's management access check short-circuits on a NULL userId, so any authenticated user could read, list, delete, or regenerate the token of another user's personal provider — and regenerating rotates it, breaking the legitimate integration while handing the caller a working token.

The 1.6.x line is unpatched upstream; the only upstream fix is the breaking 1.7.0-beta.4+. Closed here in two halves, both required:

  1. providerOwnership: { enabled: true } — the advisory's supported workaround, which stamps userId at creation so the check actually fires.
  2. Migration 0184 — the flag alone is a half fix, since the column it adds is nullable and nothing backfills it. 0184 seals pre-existing ownerless personal providers to a reserved owner id.

A sentinel rather than the advisory's suggested DELETE: it fails closed against every real user while preserving the row and its token, mirrors what upstream 1.7.0 does, and is reversible — an operator reclaims a connection by setting userId to the intended owner and regenerating the token.

Active provisioning is unaffected. /scim/v2/* authenticates on the Bearer token and never consults provider.userId; only the management endpoints use the ownership check. A sealed connection keeps syncing users.

Organization-scoped providers were never affected — they take the membership/role branch, which already enforces org membership and role.

Scope on Atlas Cloud

Verified against all three prod region databases before release: zero scimProvider rows in us, eu, and apac, so 0184 seals nothing on Cloud. The migration is defensive for future rows and for self-hosted EE deployments with existing connections. A deployment that never enabled SCIM is a no-op — both the table and column guards skip.

Release mechanics

Cut from v0.1.0 rather than main, per release-process.md § "When main is NOT a safe hotfix source": main carries the unreleased Brain M1 arc, so tagging from main would have shipped it. CI was run against this exact SHA by workflow_dispatch (13/13 green). CodeQL does not run on hotfix branches (main-only default setup) — accepted consciously, per the same section.