CVE-2026-121802 in better-auth
Summary
by MITRE • 11/04/2026
@better-auth/expo before 1.7.16 allows certain account-takeover outcomes (e.g., unauthenticated changes of any account's email address), because it signs a caller-supplied state value without checking whether that value had been issued by the server. NOTE: the application secret must be rotated after updating to a fixed version.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in @better-auth/expo versions prior to 1.7.16 represents a critical authentication bypass mechanism rooted in improper validation of cryptographic state parameters. This flaw allows attackers to manipulate session states, leading directly to account takeover scenarios where an adversary can perform unauthenticated modifications to user accounts, most notably changing the email address associated with any existing account without possessing valid credentials for that specific identity. The core technical deficiency lies in how the library handles signed tokens or state values during authentication flows; specifically, it accepts a caller-supplied state value and signs it without verifying whether this value was originally issued by the trusted server side of the application. This lack of origin verification means that an attacker can craft arbitrary state payloads, sign them using known or derived keys, and submit these forged tokens to the backend service which will then process them as legitimate requests due to the valid signature, thereby trusting maliciously constructed inputs over authentic session data.
From a technical perspective, this issue aligns with CWE-287 Improper Authentication because the system fails to correctly verify that the entity initiating the action is indeed who it claims to be or possesses authorized state context. Furthermore, the exploitation vector relates closely to CWE-345 Insufficient Verification of Data Authenticity as the application relies on a signature without ensuring the integrity and origin of the data being signed. In terms of MITRE ATT&CK mapping, this vulnerability facilitates Account Manipulation techniques where an attacker modifies account properties such as email addresses or passwords to maintain persistence or escalate privileges. The ability to change an email address is particularly dangerous because it often serves as a primary recovery mechanism for accounts; by hijacking the email field, an attacker can subsequently reset passwords and fully seize control of the compromised identity while locking out the legitimate owner.
The operational impact of this vulnerability extends beyond simple unauthorized access, affecting data integrity and user trust across platforms utilizing @better-auth/expo. Since the flaw permits unauthenticated changes to any account's email address, it effectively neutralizes multi-factor authentication protections that rely on email-based verification codes or notifications. An attacker who successfully exploits this can redirect all future security alerts and recovery links to an email address they control, ensuring long-term access even if other credentials are rotated. This creates a persistent threat landscape where the application’s trust model is fundamentally broken, allowing for widespread account compromise without requiring initial valid authentication tokens beyond what might be easily guessable or intercepted in transit depending on implementation details.
To mitigate this risk immediately upon upgrading to version 1.7.16 or later, organizations must execute a comprehensive incident response protocol that includes rotating the application secret key used for signing these state values. This rotation is critical because existing forged tokens generated under the old secret may still be valid until they expire; changing the secret invalidates all previously signed malicious payloads and forces re-authentication with properly validated server-issued states. Additionally, developers should review their authentication flows to ensure that any client-supplied state or token data undergoes strict validation against a whitelist of known good prefixes or formats before being processed by cryptographic signing functions. Implementing additional checks such as binding the session state to specific IP addresses or user agents can further reduce the attack surface for similar future vulnerabilities, ensuring that even if signature verification is bypassed through other means, contextual anomalies will trigger rejection of the request.