CVE-2026-109346 in better-auth
Summary
by MITRE • 10/12/2026
better-auth from 1.3.8-beta.3 before 1.7.0-rc.3 contains a UI misrepresentation vulnerability in the deviceAuthorization plugin because GET /device omits the requesting client_id and scope. Attackers can start a device request via /device/code, trick signed-in users into approving the code, then redeem it at /device/token for a live session token.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/12/2026
The better-auth library version 1.3.8-beta.3 through 1.7.0-rc.3 contains a significant UI misrepresentation vulnerability within its deviceAuthorization plugin that undermines user trust and facilitates unauthorized access. This flaw stems from the GET /device endpoint failing to display critical contextual information, specifically omitting the requesting client_id and scope parameters in the user interface presented during the authorization flow. In standard OAuth 2.0 Device Authorization Grant implementations, users are expected to review the application name or identifier along with the specific permissions being requested before approving access. By stripping these details from the approval screen, the vulnerability creates a deceptive environment where users cannot verify which client is requesting authentication or what level of access they are granting.
This omission allows attackers to exploit the lack of transparency by initiating a device authorization request via the /device/code endpoint using their own malicious application identifier and scope parameters. The attacker then directs a victim who is already signed into better-auth to visit the provided verification URI, such as https://better-auth.com/verify?user_code=XXXXXX. Because the interface does not display the actual client_id or scope associated with the request, the user sees only generic prompts asking them to approve access without any indication of the malicious nature of the application. The victim, assuming they are approving a legitimate service based on prior trust in the platform, approves the code.
Once the user approves the authorization code on their device, the attacker can redeem this code at the /device/token endpoint using the same client_id and scope that were originally submitted but hidden from the user interface. This redemption process results in the issuance of a live session token for the malicious application. Consequently, the attacker gains authenticated access to the victim's account with the permissions defined by the requested scope, effectively bypassing the intended security controls designed to prevent unauthorized third-party applications from accessing user data. The vulnerability relies heavily on social engineering principles where the lack of information leads users to make uninformed decisions regarding consent.
From a technical classification perspective, this issue aligns closely with CWE-200: Information Exposure and CWE-359: Privacy Violation due to the failure to provide necessary context for user decision-making. It also maps to MITRE ATT&CK technique T1648: Supply Chain Compromise if the attacker leverages a trusted provider, or more directly to techniques involving deceptive interfaces that manipulate user consent. The core issue is not necessarily a code execution flaw but rather a design failure in the human-computer interaction layer of the authentication protocol, which falls under CWE-352: Cross-Site Request Forgery in terms of exploiting trust relationships, although it is specifically an abuse of the OAuth flow mechanics.
To mitigate this vulnerability, developers and users should immediately upgrade to better-auth version 1.7.0-rc.3 or later where these UI elements are correctly rendered. For organizations still using affected versions, implementing a Web Application Firewall rule that monitors for unusual patterns in device authorization requests may provide limited detection capabilities, though it is not a definitive fix. The most effective remediation involves ensuring that the user interface explicitly displays the client identifier and scope during every step of the OAuth 2.0 Device Authorization Grant flow. Security teams should also conduct audits to ensure no other endpoints omit critical context information that could lead to similar misrepresentation attacks, thereby maintaining transparency and integrity in authentication processes.