HighGHSA-q84f-53jg-9ppm28 Sep · 25 days ago
Source ↗

better-auth: Device login approval does not show the requesting client or permissions.

Does it affect you?

Not read yet

Conditions are read within the hour after an advisory comes in.

Am I affected? You may be affected if you use better-auth from 1.3.8-beta.3 up to, but not including, 1.7.0-rc.3 , and you enable the deviceAuthorization() plugin. This range includes all 1.6 releases. You are affected only if all of these are also true: - An attacker can start a device request: validateClient is not configured, or the attacker can use a valid public client. - Before allowing approval, your approval page does not show, from server-checked data, which client is asking and the exact permissions it requests. - Users may approve a code or complete verification link they did not st

SourcesGitHub advisory

Timeline

28 Sep
25 daysfrom publication to Patchwire
  1. Published by GitHub advisory28 Sep
  2. Seen by Patchwire23 Oct
  3. Fix released28 Sep
better-auth1.7.0-rc.3

Versions of better-auth

1.x
safe 1.7.0-rc.3
AffectedSafe

Packages

better-auth

Stacks

Better Auth

Related alerts(3)

Same packages

@better-auth/drizzle-adapter: Concurrent requests can exceed rate limits on PostgreSQL

@better-auth/drizzle-adapter · 30 Sep

Low
Conditions not read yet

Source summary

Am I affected? You are affected if you use @better-auth/drizzle-adapter from 1.6.17 through versions before 1.7.7 (including the 1.7.0 prereleases from beta.6 through rc.6) or stable 1.6.x releases of @better-auth/kysely-adapter from 1.6.17 onward, and keep rate-limit records in a PostgreSQL database. This also applies when you use the affected Drizzle adapter bundled with better-auth . All of these must be true: - Rate limiting is enabled. - Rate-limit records are stored in the database. - The database is PostgreSQL, used through one of the adapter versions above. You are not affected if you

Affected
@better-auth/drizzle-adapter >=1.6.17 <1.7.7 · @better-auth/kysely-adapter >=1.6.17 <1.7.0 · better-auth >=1.6.17 <1.7.7
Fixed in
1.7.7 · 1.7.0
ID
GHSA-44jh-23m7-hpcf
Open the alert

better-auth: OAuth Proxy lets an attacker sign in as another user

better-auth · 30 Sep

High
Conditions not read yet

Source summary

Am I affected? You may be affected if you use better-auth from 1.5.0-beta.12 through versions before 1.7.7 with the OAuth Proxy plugin. You are affected only if all of these are also true: - On a participating environment, the OAuth Proxy plugin has no dedicated secret , or its secret equals that environment's global Better Auth secret. - Sign-in state is stored in a cookie ( account.storeStateStrategy: "cookie" ). With a database or secondary storage, this is only the case if you chose it explicitly. - Implicit account linking is on (the default). You are not affected by this path if every pa

Affected
better-auth >=1.5.0-beta.12 <1.7.7
Fixed in
1.7.7
ID
GHSA-r4xp-prcw-77qf
Open the alert

better-auth: OAuth state can be used as a Magic Link to sign in as another user

better-auth · 30 Sep

Critical
Conditions not read yet

Source summary

Am I affected? You may be affected if you use better-auth from 1.4.0-beta.18 through versions before 1.7.7 with the Magic Link plugin and social or Generic OAuth sign-in. You are affected if all of these are true: - Magic Link is enabled with default storeToken: "plain" , or with storeToken: "hashed" and global verification.storeIdentifier: "hashed" (including a hashed default). - At least one built-in social provider or Generic OAuth provider is enabled. - OAuth state uses account.storeStateStrategy: "database" , the default when a database or secondary storage is configured. Cookie-backed st

Affected
better-auth >=1.4.0-beta.18 <1.7.7
Fixed in
1.7.7
ID
GHSA-965c-763c-88jm
Open the alert