Better Auth June 2026 Security Update: OAuth, SSO and SCIM
What the June 2, 2026 Better Auth update fixed in OAuth, SSO and SCIM, which setups it applied to, and what to read in your own project.
Founder, Newly
Published Last updated
Better Auth published a security update on June 2, 2026 covering 13 advisories across its core, OAuth provider, SSO and SCIM packages, including a critical SSO flaw. If your project depends on better-auth, list the plugins you enable, move each package to the fixed version in its advisory, and redeploy the auth server. Most of these flaws need a particular plugin to be switched on.
What are the key facts?
| Fact | Detail |
|---|---|
| Published | June 2, 2026, on the Better Auth blog |
| Size | 13 advisories in the blog table: core, @better-auth/oauth-provider, @better-auth/sso and @better-auth/scim |
| Stable release that day | better-auth 1.6.14 |
| Highest severity listed | Critical, for the SSO plugin (CVSS 9.6, CVE-2026-53513) |
| What Better Auth tells you to do | Update stable projects to the latest better-auth, and update the scoped packages (sso, scim, oauth-provider) too |
| Newer advisories | Yes, from August and September 2026; see the section further down |
| Checked | October 24, 2026 |
What did the June update fix?
Better Auth is an open source TypeScript library that adds sign-in, sessions and account features to your own server. It has an Expo integration and keeps session tokens on the phone in expo-secure-store, so apps built with React Native and Expo can use it. The table lists the advisories I could open on GitHub. Each affects a specific plugin or setting.
| Feature | What the advisory says | Fixed in |
|---|---|---|
| SSO plugin Critical | Any signed-in user could make the server fetch and read internal URLs when registering a custom OIDC provider (GHSA-5rr4-8452-hf4v). | @better-auth/sso 1.6.11 |
| Implicit account linking High | An OAuth sign-in could link to an account someone registered in advance with the same email, when email and password sit alongside OAuth (CVE-2026-53516). | better-auth 1.6.11 |
| Device authorization High | Any signed-in user could approve or deny another person's device sign-in, only where the plugin is enabled (CVE-2026-45337). | better-auth 1.6.11 |
| Organization invitations High | An unverified account could accept an invitation sent to its email, in apps that allow sign-in before email verification (CVE-2026-53514). | 1.6.11 per the advisory, 1.6.14 per the blog table |
| SCIM plugin High | With providerOwnership off, which was the default, any signed-in user could take over another user's personal SCIM provider (GHSA-j8v8-g9cx-5qf4). | @better-auth/scim 1.7.0-beta.4 and 1.7.0 |
| OIDC provider and MCP plugins Moderate | Refresh tokens were accepted without checking the client secret, for confidential clients only (CVE-2026-53512). | better-auth 1.6.11 |
| oauth-provider Moderate | The clientPrivileges option did not limit who could create OAuth clients (CVE-2026-41427). | @better-auth/oauth-provider 1.6.5 |
Severity labels differ
The blog table and the GitHub pages do not always agree. For the OIDC refresh token flaw, the blog table lists a higher severity than the advisory's Moderate. Go by the advisory for the package you run and by its patched version, and treat the blog as the index.
Does the update affect my app?
Answer three questions in order. Each one narrows the list.
1. Is Better Auth in the project at all?
Search package.json and the lockfile for better-auth and anything under @better-auth/. You can download your code from Newly or connect your own repository, so this takes a minute. If nothing matches, this update is not about your app. Look at whichever sign-in service the project does use.
2. Which plugins are switched on?
Open the file where you call betterAuth and read the plugins array. The SSO, SCIM, device authorization, OIDC provider, MCP, organization and magic link plugins are each opt-in. A flaw in a plugin you do not enable does not reach you, but remove plugins you added during a prototype and never used.
3. Which versions does the lockfile resolve?
Run npm ls better-auth and the same for each scoped package. Compare the printed version with the fixed version in the table above. A caret range in package.json only helps if the lockfile was refreshed and the server was rebuilt after the fixed release came out.
Updating the app build on a phone leaves all of this unchanged. As the diagram further down shows, the auth server owns the package, so the fix is a dependency update and a redeploy of that server. For the wider pre-publish list, see the pre-launch review for vibe-coded apps and the 15-minute check.
What has Better Auth fixed since June?
At our check on October 24, 2026, the advisory list showed more entries after the June post. The project's blog index showed no second security update post after June 2, so these live only on GitHub. I opened three of them in full.
| Published | Package and issue | Fixed in |
|---|---|---|
| August 11, 2026 | @better-auth/sso: unproven domain claims can allow account takeover or organization joins (High) | 1.6.27 on the 1.6 line, 1.7.0-rc.5 on 1.7 |
| September 29, 2026 | @better-auth/sso: personal SSO providers matched accounts from another provider, 1.7 line only (High) | 1.7.3 |
| September 30, 2026 | OAuth state usable as a magic link, when the magic link plugin and an OAuth provider are both on (Critical, CVE-2026-114607) | 1.7.7 |
| Also listed | Magic link and email OTP password handling (June 26), device login approval screen (September 28), OAuth Proxy (September 30), a rate limit issue on the Drizzle adapter (September 30) | See each advisory |
Better Auth shipped 1.7 on August 17, 2026 and posted a note on September 7 about a database change that broke some upgrades. Read that note on the blog index before you move across the 1.6 to 1.7 line, and take a database backup first. If you stay on 1.6, use the highest 1.6 fix each advisory names.
Where does the fix live in an Expo app?
The package runs on whichever machine answers your sign-in requests. For a project that keeps the backend in a separate service, that is where you run the update. For one that hosts the auth routes inside the Expo project, as the integration docs allow, it is the server build of that project. Either way the sequence is the same:
- Update the packages and commit the new lockfile.
- Redeploy the server, and note the build identifier or deploy time.
- Open your auth configuration and read the settings in the next section.
- Review your records for providers, clients and links you do not recognise.
The SSO fix is about a server fetching addresses it was handed. OWASP's SSRF prevention guidance recommends allowlists for known destinations, blocking private and cloud metadata addresses, and turning off redirect following. The sibling page on SSRF and cloud metadata explains why that matters for the credentials your server can reach. If a flaw like this was open on a server holding cloud credentials, the secret rotation checklist is the next step.
Which settings should I read?
Updating closes the specific bugs. Your configuration decides how much a future one can reach. These are the lines to look for.
| Setting | What to look for | What the result means |
|---|---|---|
accountLinking.trustedProviders | Providers listed there link to an existing account without an email verification check. The docs warn this may raise the risk of account takeover. | A provider you cannot justify is a finding. Remove it, or mark the item unknown until you can. |
disableImplicitLinking | Whether automatic linking on sign-in is switched off, so a person must confirm a link. | If it is absent, implicit linking is on. That is the setting the June linking advisory concerns. |
providerOwnership | In the SCIM plugin configuration. SCIM is a standard protocol for managing identities across systems. | If you do not provision users from a company directory, remove the SCIM plugin. |
clientPrivileges | Who may create OAuth clients if you run an OAuth provider, and whether those endpoints are reachable by every signed-in user. | Registered clients you did not create are the thing to hunt for. |
| SSO domain verification | Whether the SSO plugin has domain verification enabled, and who may register providers. | Open registration plus domain-based account matching is the combination the August advisory describes. |
If you sold or published an app built this way, keep a short dated note of what you read and the versions you found. It is the thing to show a client who asks whether the update was applied. The same advice on proving a fix applies to any dependency, and it is why this page sorts results into detected, unknown and confirmed by owner evidence.
Where do you stand?
Mark each item. Every one starts as unknown. Move it to confirmed only when you hold the evidence listed under it, and keep the dated note.
Better Auth update check
- Detected: You found the problem.
- Unknown: Not checked yet, or the check could not tell.
- Confirmed by owner evidence: You checked and kept the proof.
Your answers stay in this browser tab. Nothing is saved or sent.
What no outside check can settle
A scan from outside does not see your lockfile, your plugin list or your database rows. Whether these flaws were used against your app stays unknown until you read your own records. This page is also not a statement about Better Auth as a whole: the advisories show a project that publishes and fixes its issues, and the work left is yours.
Frequently asked questions
Does updating my mobile app fix this?
No. Better Auth runs on your auth server, and the phone only holds a session token. The fix is the package version on the server, so the change happens when you update the dependency and redeploy that server. A new app build alone changes nothing about it.
I only use email and password. Do I need to do anything?
Probably yes, for one reason: the update touched core as well as plugins. At least one core advisory, the implicit account linking one, applies when email and password sign-in sits next to an OAuth provider, and the others depend on plugins you may not use. Read the plugin table on this page, then update anyway, because the update path is a version bump.
Is 1.6.14 still the version to run?
It was the current stable release on June 2, 2026, and it is not the newest fix level any more. Advisories published on September 29 and 30, 2026 name 1.7.3 and 1.7.7 as patched versions for plugins and a magic link flaw. Check the advisory page for each package you run, and read Better Auth's September 7 note on the 1.7 account change before you move to 1.7.
How do I know whether anyone used these flaws against my app?
From the outside you cannot tell, and neither can a scan. Look at your own records: new SSO providers or OAuth clients you did not create, accounts linked to a provider their owner does not recognise, and organization members who never received an invitation. Treat the absence of those as unknown, not as confirmed.
Will the red.run.cloud scan find an outdated Better Auth?
Do not count on it. The free scan reads the stack your site serves and matches versions to known vulnerabilities. A server-side library whose version is never sent to a browser is usually invisible to it, so that result would be unknown. Your lockfile and your deployed build are the evidence for this one.
Sources
All pages opened on October 24, 2026. Severity, CVSS and version figures come from the linked advisories.
- Security update: June 2026, Better Auth blog (checked October 24, 2026)
- GHSA-5rr4-8452-hf4v, @better-auth/sso server-side requests, GitHub Security Advisories, CVE-2026-53513
- GHSA-pw9m-5jxm-xr6h, refresh tokens without client secret, GitHub Security Advisories, CVE-2026-53512
- GHSA-cq3f-vc6p-68fh, device sign-in approval, GitHub Security Advisories, CVE-2026-45337
- GHSA-g38m-r43w-p2q7, implicit account linking, GitHub Security Advisories, CVE-2026-53516
- GHSA-fmh4-wcc4-5jm3, organization invitations, GitHub Security Advisories, CVE-2026-53514
- GHSA-j8v8-g9cx-5qf4, SCIM personal providers, GitHub Security Advisories
- GHSA-xr8f-h2gw-9xh6, oauth-provider clientPrivileges, GitHub Security Advisories, CVE-2026-41427
- GHSA-965c-763c-88jm, OAuth state and magic link, GitHub Security Advisories, CVE-2026-114607
- GHSA-8c5h-wx78-2cfg, unproven SSO domain claims, GitHub Security Advisories
- GHSA-mx9r-x6ww-qjw9, personal SSO providers, GitHub Security Advisories
- Better Auth security advisories (full list), GitHub
- Better Auth blog index (1.7 and the account change note), Better Auth
- Expo integration, Better Auth docs
- Users and accounts: account linking, Better Auth docs
- Single Sign-On plugin, Better Auth docs
- Server Side Request Forgery Prevention Cheat Sheet, OWASP Cheat Sheet Series
- RFC 7644: SCIM Protocol, IETF