Better Auth CVE-2026-109346

Exploitation requires that the target better-auth instance has the deviceAuthorization plugin enabled and the OAuth 2.0 device flow endpoints (/device/code, /device, /device/token) exposed; instances not using device authorization are unaffected. The specific defect is that the GET /device approval screen omits the requesting client_id and scope, so the victim cannot distinguish a legitimate from a malicious request. Exploitation is further limited by a hard dependency on user interaction (UI:A): a currently signed-in, authenticated user must be tricked into visiting and approving the attacker-initiated device code, so success depends on effective social engineering rather than a purely technical trigger.

This is a credible, elevated-priority issue for anyone running the better-auth deviceAuthorization plugin, but it is not a drop-everything emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H) correctly captures the core dynamic: a network-based, unauthenticated attacker can start the flow, but exploitation hinges on user interaction (UI:A) - a signed-in victim must be socially engineered into approving the attacker's device code. The high VC:H/VI:H impact is justified because a redeemed device code yields a live session token, effectively full account takeover. Working against the raw 8.5 score: there is no CISA KEV listing and no public exploit code identified, so this is not confirmed active exploitation - the primary limiter is the phishing/consent step, which places real-world success on par with other OAuth device-code phishing campaigns rather than wormable mass exploitation. No EPSS score was provided in the input, so exploitation probability cannot be quantified here. The decisive risk factor is whether the deviceAuthorization plugin is actually enabled; most better-auth deployments that do not use device flows are not exposed at all.

An attacker calls POST /device/code to begin a device authorization request for their own client, then sends the resulting verification URL/code to a signed-in better-auth user via a phishing message disguised as a legitimate device-linking prompt. Because GET /device omits the requesting client_id and scope, the victim's consent screen gives them no way to see they are authorizing an attacker, so they approve; the attacker then polls /device/token and receives a live session token for the victim's account. No public exploit code was identified at time of analysis, though the attack requires only standard HTTP requests against the documented device-flow endpoints.