https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 10 Oct 2026 08:20:19 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-338097 EUVD-2026-338097 https://cve.radiocsirt.org/vuln/euvd-2026-338097 https://cve.radiocsirt.org/vuln/fkie_cve-2026-53516 <p>Better Auth is an authentication and authorization library for TypeScript. Prior to 1.6.11, Better Auth&#39;s OAuth callback auto-link gate in handleOAuthUserInfo accepts implicit account linking when the OAuth provider asserts email_verified: true without requiring the local user row&#39;s emailVerified field to also be true, allowing an attacker who pre-registers a victim email through /sign-up/email to bind the victim&#39;s OAuth identity to the attacker&#39;s account. The same primitive affects one-tap, and emailAndPassword.requireEmailVerification: true does not mitigate the link-time verification change. This issue is fixed in version 1.6.11.</p> <p>Better Auth is an authentication and authorization library for TypeScript. Prior to 1.6.11, Better Auth&#39;s OAuth callback auto-link gate in handleOAuthUserInfo accepts implicit account linking when the OAuth provider asserts email_verified: true without requiring the local user row&#39;s emailVerified field to also be true, allowing an attacker who pre-registers a victim email through /sign-up/email to bind the victim&#39;s OAuth identity to the attacker&#39;s account. The same primitive affects one-tap, and emailAndPassword.requireEmailVerification: true does not mitigate the link-time verification change. This issue is fixed in version 1.6.11.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-53516 https://cve.radiocsirt.org/vuln/ghsa-g38m-r43w-p2q7 <p><strong>Affected:</strong> npm: better-auth</p> <p>### Am I affected?</p> <p>Users are affected if all of the following are true:</p> <p>- Their application uses `better-auth` at a version `&lt; 1.6.11` on the stable line, or any current `next` pre-release. - `emailAndPassword.enabled: true` is set in their application&#39;s `betterAuth({ ... })` configuration. - At least one OAuth or SSO provider is configured (any built-in social provider, or `genericOAuth(...)`, or any provider via `@better-auth/sso`). - `account.accountLinking.disableImplicitLinking` is not set to `true`. - `account.accountLinking.enabled` is not set to `false`.</p> <p>Setting either `disableImplicitLinking: true` or `enabled: false` closes the hole at the cost of breaking the standard &#34;add another login method&#34; UX. `emailAndPassword.requireEmailVerification: true` does not mitigate, because the link-time `emailVerified` flip promotes the attacker&#39;s row to verified, after which the password login becomes usable.</p> <p>Fix:</p> <p>1. Upgrade to `better-auth@1.6.11` or later. 2. If developers cannot upgrade, see workarounds below.</p> <p>### Summary</p> <p>The OAuth callback&#39;s auto-link gate in `handleOAuthUserInfo` admits an implicit account link whenever the provider asserts `email_verified: true`, without requiring the local user row&#39;s `emailVerified` to also be `true`. An attacker who pre-registers a victim&#39;s email through `/sign-up/email` (which writes a row with `emailVerified: false`) can have the victim&#39;s later OAuth identity bound to the attacker&#39;s user row, granting both a password login and t…</p> <p><strong>Affected:</strong> npm: better-auth</p> <p>### Am I affected?</p> <p>Users are affected if all of the following are true:</p> <p>- Their application uses `better-auth` at a version `&lt; 1.6.11` on the stable line, or any current `next` pre-release. - `emailAndPassword.enabled: true` is set in their application&#39;s `betterAuth({ ... })` configuration. - At least one OAuth or SSO provider is configured (any built-in social provider, or `genericOAuth(...)`, or any provider via `@better-auth/sso`). - `account.accountLinking.disableImplicitLinking` is not set to `true`. - `account.accountLinking.enabled` is not set to `false`.</p> <p>Setting either `disableImplicitLinking: true` or `enabled: false` closes the hole at the cost of breaking the standard &#34;add another login method&#34; UX. `emailAndPassword.requireEmailVerification: true` does not mitigate, because the link-time `emailVerified` flip promotes the attacker&#39;s row to verified, after which the password login becomes usable.</p> <p>Fix:</p> <p>1. Upgrade to `better-auth@1.6.11` or later. 2. If developers cannot upgrade, see workarounds below.</p> <p>### Summary</p> <p>The OAuth callback&#39;s auto-link gate in `handleOAuthUserInfo` admits an implicit account link whenever the provider asserts `email_verified: true`, without requiring the local user row&#39;s `emailVerified` to also be `true`. An attacker who pre-registers a victim&#39;s email through `/sign-up/email` (which writes a row with `emailVerified: false`) can have the victim&#39;s later OAuth identity bound to the attacker&#39;s user row, granting both a password login and t…</p> https://cve.radiocsirt.org/vuln/ghsa-g38m-r43w-p2q7