Summary
better-auth: OAuth Proxy lets an attacker sign in as another user
Am I affected?
You may be affected if you use better-auth from 1.5.0-beta.12 through versions before 1.7.7 with the OAuth Proxy plugin. You are affected only if all of these are also true:
- On a participating environment, the OAuth Proxy plugin has no dedicated
secret, or itssecretequals that environment's global Better Auth secret. - Sign-in state is stored in a cookie (
account.storeStateStrategy: "cookie"). With a database or secondary storage, this is only the case if you chose it explicitly. - Implicit account linking is on (the default).
You are not affected by this path if every participating environment uses a proxy secret distinct from its global Better Auth secret, if sign-in state is stored in the database, or if you use a version before 1.5.0-beta.12.
The OAuth Proxy plugin trusts any user profile it can decrypt. In the affected setup, Better Auth encrypts sign-in state, including data the caller chose, with the same secret and hands it to anyone who starts a social sign-in. An attacker can use this to get a fake profile for another user's email address that the proxy accepts as real.
Workarounds
Until you upgrade to the fixed release, apply one of these:
- Set one strong OAuth Proxy
secretacross every environment that takes part in the proxy flow, and keep it different from each environment's global Better Auth secret. - Set
account.storeStateStrategy: "database". This is already the default when a database or secondary storage is configured. If Magic Link is also enabled, switching can expose a separate cross-purpose verification-record path in affected releases. Ensure the two flows resolve to distinct stored identifiers; with built-in options, use Magic LinkstoreToken: "hashed"with globalverification.storeIdentifierunset or"plain", or disable Magic Link or both built-in social and Generic OAuth sign-in. - Remove the OAuth Proxy plugin if you do not need it.
Setting account.accountLinking.disableImplicitLinking: true stops this path from taking over an existing account. It does not fix the underlying flaw: the callback can still accept attacker-made data as a provider identity. Apply one of the steps above as well.
Impact
An attacker without an account who knows a user's verified email address can sign in as that user, with that user's permissions. They can read private data, change the account, and link a provider account of their choice to it. They need no provider sign-in and no action from the victim. No availability impact is established, and a reported open redirect was not confirmed.
The application does not adequately verify the identity of a user, device, or process before granting access. Typical impact: unauthorized access to functions or data reserved for authenticated parties.
GHSA-R4XP-PRCW-77QF has a CVSS score of 7.4 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.7.7); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
The fix is merged for the planned better-auth 1.7.7 release. That package is not available yet.
Upgrade all nodes handling the same cookie-backed OAuth or SAML state flow and all OAuth Proxy participants together, including the production coordinator and preview or development deployments. Keep installed Better Auth packages released alongside better-auth on the same release version. Restart pending sign-in and account-linking flows; pre-upgrade state cookies and proxy payloads are rejected. Public options and API signatures are unchanged.
Frequently Asked Questions
- What is GHSA-R4XP-PRCW-77QF? GHSA-R4XP-PRCW-77QF is a high-severity improper authentication vulnerability in better-auth (npm), affecting versions >= 1.5.0-beta.12, < 1.7.7. It is fixed in 1.7.7. The application does not adequately verify the identity of a user, device, or process before granting access.
- How severe is GHSA-R4XP-PRCW-77QF? GHSA-R4XP-PRCW-77QF has a CVSS score of 7.4 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of better-auth are affected by GHSA-R4XP-PRCW-77QF? better-auth (npm) versions >= 1.5.0-beta.12, < 1.7.7 is affected.
- Is there a fix for GHSA-R4XP-PRCW-77QF? Yes. GHSA-R4XP-PRCW-77QF is fixed in 1.7.7. Upgrade to this version or later.
- Is GHSA-R4XP-PRCW-77QF exploitable, and should I be worried? Whether GHSA-R4XP-PRCW-77QF is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-R4XP-PRCW-77QF is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-R4XP-PRCW-77QF? Upgrade
better-authto 1.7.7 or later.