CVE-2026-109346 is a high severity UI misrepresentation flaw (CVSS 8.1) in better-auth. The device authorization approval page leaves out the requesting client and permissions, so a signed-in user can be tricked into approving an attacker's code. The fix first shipped in 1.7.0-rc.3.
What's affected
The record says better-auth from 1.3.8-beta.3 before 1.7.0-rc.3 is affected. The GitHub advisory GHSA-q84f-53jg-9ppm, published on 28 September 2026 and rated High, says the same range and adds that it includes all 1.6 releases and that no 1.6 release contains the fix. It advises upgrading to 1.7.0 or later. VulnCheck rates the issue 8.5 under CVSS 4.0, against the record's 8.1 under CVSS 3.1.
The weakness is CWE-451, user interface misrepresentation of critical information. The vector is network reachable, low complexity, no privileges, with user interaction required, and high confidentiality and integrity impact.
The advisory limits who is affected. You are affected only if you enable the opt in deviceAuthorization plugin, and an attacker can start a device request, either because validateClient is not set or because a valid public client can be used, and your approval page does not show server checked client and scope information. Without the plugin, you are not affected.
The advisory says this is not a sign in bypass without user action: a person has to approve the attacker's code.
How to check if you're exposed
Find out if you use the plugin at all:
npm ls better-auth
grep -rn "deviceAuthorization" src/ lib/ app/ 2>/dev/null
If the second command finds nothing, you probably do not enable the plugin. If it finds a match, check the version against the range, from 1.3.8-beta.3 up to below 1.7.0-rc.3.
Then look at your approval page. Does it show which client is asking and which permissions it wants, taken from server checked data? The advisory says official approval examples in affected versions show only a generic request and a code. If you built your own page, the advisory says to update it to show the client and the scope.
Finally check your validateClient setting and whether you restrict which clients can start a flow.
What to do now
- Upgrade better-auth to 1.7.0 or later, as the advisory recommends. The fix first appeared in 1.7.0-rc.3.
- If you built your own approval page, update it to display the client id and the scope returned by the device endpoint, and keep approval disabled until they load.
- If you cannot upgrade, disable the deviceAuthorization plugin or block untrusted access to the device code endpoint.
- Set a strict validateClient allowlist, knowing it limits who can start a flow but does not give users the missing information.
- Tell users to approve a device code only when they started the request themselves.
Why it matters
The device flow exists for screens that have no keyboard, like a television. The device shows a short code, and the user approves it on a phone or computer where they are already signed in. Safety relies on the user knowing that the code on the approval page belongs to the device in front of them.
When the approval page says nothing about which client asked and what it wants, a user cannot tell their own device from an attacker's. An attacker starts a request, sends the code to a signed in user with a believable reason, and gets a live session token for that account once the user approves. The advisory says the attacker can then read or change any data the account can reach.
This is an old phishing pattern with a new door. The fix is to show the facts the user needs to decide: who is asking and for what. The record does not mark this CVE as known exploited.
Quick check
Am I affected if I do not use the device plugin?
No. The advisory says you are not affected if you do not enable the opt in deviceAuthorization plugin.
Is an allowlist of clients enough?
The advisory says no. It limits who can start the flow but does not give users the missing approval information.
Sources
You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see which of your packages carry known CVEs.
Last reviewed: 18 October 2026.
