[superbot-helper]

• Branch created from canary (the repository's default branch)
• Read CONTRIBUTING.md
• Tested locally (commands and results below)

Bumps the Better Auth suite from 1.6.23 to 1.6.34. @better-auth/sso
1.6.23 is affected by GHSA-8c5h-wx78-2cfg, where an unproven SSO domain
claim can allow account takeover or organization joins. The fix on the
1.6 line is @better-auth/sso 1.6.27; 1.6.34 is the latest 1.6.x patch
and includes it.

Advisory	Package	Affected	Patched	Severity	Global DB
GHSA-8c5h-wx78-2cfg	@better-auth/sso	>=1.4.9 <=1.6.26, >=1.7.0-beta.0 <=1.7.0-rc.4	1.6.27 / 1.7.0-rc.5	high, CVSS 8.1	404
GHSA-prpr-5gj3-qqhg	@better-auth/sso	<=1.6.20, >=1.7.0-beta.0 <1.7.0-beta.10	1.6.21 / 1.7.0-beta.10	high, CVSS 8.1	404
GHSA-mx9r-x6ww-qjw9	@better-auth/sso	>=1.7.0-rc.2 <1.7.0, >=1.7.0 <1.7.3	1.7.3	high, CVSS 8.1	404

Which advisories this clears: GHSA-8c5h-wx78-2cfg only.

• GHSA-prpr-5gj3-qqhg was already fixed at 1.6.23: it affects <=1.6.20.
• GHSA-mx9r-x6ww-qjw9 does not affect the 1.6 line at all; it covers
  1.7.0-rc.2 through 1.7.0-rc.6 and 1.7.0 through 1.7.2. A 1.6.x
  bump cannot clear it. Clearing it means a minor bump to >=1.7.3, which
  is a separate migration and is intentionally not part of this patch.

None of the three records is in the global advisory database or OSV: all
three GHSA IDs return 404 from api.github.com/advisories and from
api.osv.dev/v1/vulns/. The npm bulk advisory feed returns {} for both
@better-auth/sso 1.6.23 and 1.6.34 when queried with the lowercase
package key and one exact version, so no scan delta exists for this
change — npm audit and Dependabot have no record to match. That is why
no bot PR exists for these advisories.

What this does

The SSO plugin trusts a provider for the email domains it claims.
GHSA-8c5h-wx78-2cfg has two flaws:

• With domain verification off, organization assignment trusts unverified
  domains, so an untrusted organization owner can register a provider for
  a domain they do not control and have later users with that email domain
  added to their organization.
• With domainVerification.enabled: true, the verification endpoint reads
  a provider and its domains before asynchronous DNS lookups, and the
  provider-update endpoint can change them while those lookups are
  pending. The stale proof is then written against the current domains.
  When implicit account linking is enabled this can attach an attacker's
  identity provider to an existing user's account.

1.6.27 binds domain verification to the exact provider and domain set that
passed DNS, and requires verification for automatic organization
assignment.

Reachability in Dokploy

packages/server/src/lib/auth.ts:492 registers the plugin as
sso({ trustEmailVerified: true }) without domainVerification, so both
flaws' preconditions need an untrusted user who can register or update an
SSO provider. In this repository SSO providers are not self-service:

• packages/server/src/lib/auth.ts:72-74 disables the plugin's own
  /sso/register route through disabledPaths.
• Provider registration, update and verification go through the tRPC
  router at apps/dokploy/server/api/routers/proprietary/sso.ts:261,
  which uses enterpriseProcedure (apps/dokploy/server/api/trpc.ts:219):
  an instance admin/owner and a valid enterprise license.

The advisory says a deployment is not affected when only trusted operators
can register, update or verify providers, which is Dokploy's default
configuration. This PR is therefore dependency hygiene and
defense-in-depth — it removes the affected release from the pinned
manifests and keeps Dokploy on the patched 1.6 line. It is not a claim of
a live exploit in this repository.

Change

• apps/dokploy/package.json: @better-auth/api-key,
  @better-auth/passkey, @better-auth/scim, @better-auth/sso and
  better-auth from 1.6.23 to 1.6.34.
• packages/server/package.json: the same five.
• package.json: pnpm.overrides better-call from 1.3.7 to 1.4.0,
  and add @better-auth/utils at 0.4.2.
• pnpm-lock.yaml: regenerated with the repository's own
  packageManager (pnpm@10.22.0, Node 24.22.1).

The whole suite moves together because every 1.6.34 package peers on
better-auth and @better-auth/core at ^1.6.34, and on
better-call: 1.4.0 and @better-auth/utils: 0.4.2 exactly. Bumping
@better-auth/sso alone would leave better-auth 1.6.23 outside the
plugin's ^1.6.34 peer range. The @better-auth/utils override is needed because
apps/dokploy does not declare that package directly and pnpm otherwise
auto-installs 0.5.1, reporting five unmet-peer warnings against the
exact 0.4.2 peer.

Lock churn is confined to the Better Auth packages and better-call: 18
snapshot entries added, 18 removed, 26 package names total, all
better-auth* 1.6.23 → 1.6.34 or better-call 1.3.7 → 1.4.0. No other
package version changes. The lockfile format is unchanged
(lockfileVersion: '9.0').

Verification performed on the branch

Environment: macOS arm64, Node 24.22.1, pnpm 10.22.0 (from the repo's
packageManager field).

• Control — fresh clone of canary at 78d235a:
  pnpm install --frozen-lockfile exit 0; resolves
  @better-auth/sso@1.6.23; pnpm server:build exit 0; pnpm typecheck
  exit 0; pnpm exec biome check . reports 41 errors, 101 warnings and
  42 infos — canary already fails biome check, and CI runs
  biome format, not biome check; the scoped server-barrel vitest
  suites pass (4 files, 53 tests). The branch base 9f76ae0 only adds
  unrelated server-security source files; the four files this PR
  touches and the lockfile are byte-identical between the two canary
  commits.
• Branch — fresh clone of
  security/bump-better-auth-1.6.34 at f8379af:
  pnpm install --frozen-lockfile exit 0 and git status clean after
  the install; resolves @better-auth/sso@1.6.34,
  better-auth@1.6.34, @better-auth/{api-key,passkey,scim}@1.6.34,
  better-call@1.4.0 and exactly one @better-auth/utils@0.4.2 instance
  (no 0.5.1); pnpm server:build exit 0; pnpm typecheck exit 0;
  pnpm exec biome check . produces exactly the same diagnostics as the
  control; the same scoped vitest suites pass (4 files, 53 tests).
• Lock control — regenerating the lock from the unmodified canary
  manifests produces a zero-byte diff, so the lock diff above is caused
  only by this bump and not by the pnpm version.
• Full build — fresh clone of the branch at f8379af:
  pnpm server:build exit 0 and pnpm build (pnpm -r run build) exit 0;
  packages/server, apps/dokploy (esbuild + Next.js), apps/api and
  apps/schedules all build.
• Install side effect — pnpm server:build runs the repo's
  switch:prod script, which rewrites packages/server/package.json
main/exports to the dist entries. That happens on canary too; the
  commit does not include it.

How should this be manually tested?

pnpm install --frozen-lockfile
pnpm server:build
pnpm typecheck
# SSO sign-in / organization flows against a local instance

Why this is not a bot PR

The three advisories are repository advisories in
better-auth/better-auth, not global-database records, so the npm bulk
advisory feed has nothing to match: it returns {} for @better-auth/sso
1.6.23 and 1.6.34 with the lowercase key. The repository has no
dependabot.yml and no Renovate config, and there is no existing PR for
this bump (the last Better Auth upgrade PRs were #3969 in March 2026 and
#3783 in February 2026). This PR is filed so the pinned 1.6.23 release is
replaced with the patched 1.6.x release.

Confidence Score: 5/5

The PR appears safe to merge; no actionable regression was found.

Summary

Updates the Better Auth suite from 1.6.23 to 1.6.34 in both workspace consumers.

• Dokploy's app and server use the patched Better Auth suite.

_{Reviews (1) · Last reviewed commit: "fix(deps): bump better-auth to 1.6.34 fo..." · Reviewed by Greptile}