HighVulnerabilityGHSA-q84f-53jg-9ppmupdated 27 Oct 2026, 14:50 UTC

better-auth device sign-in lets attackers trick users into approving logins

A sign-in method for logging in one device by approving a code on another can be abused. An attacker can start a login and get a user to approve it without the user knowing which app is asking or what it wants access to.

Fix availableOfficial source

Severity	HighCVSS 8.1 of 10
Being exploited?	UnclearNo reports either way yet
Fix available?	Yesbetter-auth 1.7.0-rc.3 or later (upgrade to 1.7.0 or later recommended). No 1.6 release contains the fix. · since 27 Oct 2026
How sure is this?	Official sourceBacked by an official source

How the attack works simplified

1Attacker starts requestCalls /device/code to get a short code
2User sees generic promptNo client name or permissions shown
3User approves the codeBelieves it is their own device
4Attacker gets session tokenToken is returned through the device flow
5Attacker reads account dataAccess matches the user's account
ResultAttacker gains the user's account session

What happened

In better-auth versions from 1.3.8-beta.3 up to (not including) 1.7.0-rc.3, including all 1.6 releases, the deviceAuthorization() plugin's approval page omits the requesting client and requested scopes, so users cannot verify who they are approving.

Why it is dangerous: A user who approves an attacker's code gives the attacker a live session token, letting them read or change any data that account can access. Apps using this opt-in device flow are at risk.

Are you affected?

You are affected if you use better-auth 1.3.8-beta.3 up to 1.7.0-rc.3 (including all 1.6 releases) with the deviceAuthorization() plugin enabled and accept the returned session token, for example via the bearer plugin.

Package / product	Affected versions	Fixed in
better-auth · npm	>= 1.3.8-beta.3, < 1.7.0-rc.3	1.7.0-rc.3

What to do

Upgrade better-auth to 1.7.0 or later
If you cannot upgrade, disable deviceAuthorization() or block untrusted access to /device/code
If you built a custom approval page, show the requesting client name and exact permissions, and keep approval disabled until they load
Tell users to reject device requests they did not start

Timeline

27 Oct 2026, 14:49 UTC
Publicly disclosed
27 Oct 2026, 14:49 UTC
Reported by GitHub Advisory · GitHub Advisory
27 Oct 2026, 14:50 UTC
Picked up by Zero Radar

Sources 1 report, oldest first

Official vendor, government CERT or advisory database

better-auth: Device login approval does not show the requesting client or permissionsGitHub Advisory · 27 Oct 2026, 14:49 UTC

Technical details

ID: GHSA-q84f-53jg-9ppm
CVSS: 8.1 / 10
Disclosed: 27 Oct 2026, 14:49 UTC
On Zero Radar: 27 Oct 2026, 14:50 UTC (0 min after disclosure)
Last change: 27 Oct 2026, 14:50 UTC

The plain-language parts and the attack diagram were written by an AI model (anthropic/claude-haiku-5.5) from the sources above. Facts like versions, exploitation and dates come from the sources themselves. How Zero Radar works