0-click account takeover in Better Auth
Comments on “0-click account takeover in Better Auth”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
Security firm Strix reports a critical zero-click account takeover in @better-auth/expo, Better Auth's React Native integration. The /expo-authorization-proxy endpoint signed any caller-supplied OAuth state with the app secret, without a login. Because email-verification JWTs used the same HMAC-SHA256 secret, a forged token could change a victim's email and yield a session; the compact session cache was forgeable too, though not the jwe strategy. Fixed in version 1.7.16. The lesson for builders: avoid signing oracles and reusing one key across features.
Why it ranked
No. 3 of 137 with a score of 0.75. The panel rated it highest on technical depth (0.92) and substantiated (0.91), lowest on audience breadth (0.56).
- AI judgeJudge 2claude-haiku-5-5
- Detailed, reproduced zero-click auth bypass in a widely used open-source auth library with primary evidence and coordinated disclosure; highly relevant security write-up for builders.
- AI judgeJudge 3gpt-5.6-luna
- A detailed, reproducible account-takeover vulnerability with exploit mechanics, affected configurations, validation output, disclosure, and fixes. It is highly actionable for developers, though impact is concentrated in Better Auth and its Expo integration.
Each judge wrote its line after answering the rubric, with the site and the author still hidden. Every answer behind this is in the table under Score.
Score
0.75total under rubric v2.3
- Significance0.66
- Reader interest0.88
- Audience breadth0.56
- Practical relevance0.83
- Substantiated0.91
- Technical depth0.92
- New information0.90
- Counts against: Promotional0.06
- Counts against: Overclaim0.17
Each judge’s answer per question (0–1), their mean and spread, and what the question adds to the score (weight × mean).
| Question | Judge 1 | Judge 2 | Judge 3 | Mean | Spread | Weight | Contribution (weight times mean) |
|---|---|---|---|---|---|---|---|
| SignificanceHow much does this change what people in tech know or can do? | 0.64 | 0.62 | 0.72 | 0.66 | 0.10 | +0.24 | +0.158 |
| Reader interestWould a well-informed senior engineer or tech founder want to read this today, and likely pass it on? | 0.83 | 0.85 | 0.95 | 0.88 | 0.12 | +0.26 | +0.228 |
| Audience breadthHow many people who build technology does it concern? | 0.52 | 0.60 | 0.55 | 0.56 | 0.08 | +0.13 | +0.072 |
| Practical relevanceHow useful is it to someone who builds software or tech products? | 0.83 | 0.80 | 0.86 | 0.83 | 0.06 | +0.22 | +0.183 |
| SubstantiatedHow well is it backed? Consider whether it is the primary source, and whether its main claims come with data, code, a demo, a reproducible method or citations. | 0.90 | 0.92 | 0.90 | 0.91 | 0.02 | +0.05 | +0.045 |
| Technical depthHow technically substantive is it? | 0.99 | 0.90 | 0.88 | 0.92 | 0.11 | +0.05 | +0.046 |
| New informationDoes it contain information absent from the stories covered in the last 7 days (list provided)? | 0.87 | 0.85 | 0.99 | 0.90 | 0.14 | +0.05 | +0.045 |
| PromotionalIs it mainly marketing with little substance (a press release, ad or sponsored post with no real information)? A launch post that carries real news is not promotional. | 0.05 | 0.10 | 0.03 | 0.06 | 0.07 | −0.19 | −0.011 |
| OverclaimDo the headline or conclusions claim more than the body supports? | 0.26 | 0.20 | 0.04 | 0.17 | 0.22 | −0.11 | −0.018 |
| Sum of contributions | +0.748 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.748 | ||||||
Spread is the highest minus the lowest judge answer. marks a spread above 0.40: the judges disagree, and the story is marked contested.
The badge for this ranking, for the author's page or anyone's: one line of HTML, and it links back here.
<a href="https://rubric.hrih.si/editions/2026-11-04/3/"><img src="https://rubric.hrih.si/badge/2026-11-04/3.svg" alt="Ranked #3 on Rubric, 4 Nov 2026" width="231" height="28"></a>Claim check
Claim check: 4 matches source · 4 couldn’t check. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
Matches sourceCausal conclusion
Strix found a critical zero-click account-takeover vulnerability in @better-auth/expo, Better Auth's Expo integration, where an unauthenticated attacker could get the app to sign a forged token and use it to change a victim's email and obtain their session.
The cited source says the same thing.
The article says “An unauthenticated attacker could get the application to sign a forged token, then use it to change a victim's email and obtain their session”
The source says “An unauthenticated attacker who knows a user's email address can sign in as that user and change the account's email address, with no action from the user”
Source cited by the article: github.com/better-auth/better-auth/security/advisories/GHSA-4wq4-2ppv-q3hg
Couldn’t checkDate
The fix was coordinated for Better Auth's November 3 security release, published as advisory GHSA-4wq4-2ppv-q3hg.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “coordinated disclosure for their November 3 security release”
The source says No passage could be compared.
Source cited by the article: github.com/better-auth/better-auth/security/advisories/GHSA-4wq4-2ppv-q3hg
Matches sourceVersion
The fix ships in better-auth and @better-auth/expo 1.7.16 (1.8.0-beta.5 on the beta line).
The cited source says the same thing.
The article says “the fix ships in better-auth and @better-auth/expo 1.7.16 (1.8.0-beta.5 on the beta line”
The source says “Update better-auth and every @better-auth/* package to 1.7.16, or to 1.8.0-beta.5 on the beta line”
Source cited by the article: better-auth.com/blog/security-release-2026-11-03
Couldn’t checkDate
Vercel acquired Better Auth in July 2026.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “Vercel acquired the company in July 2026”
The source says No passage could be compared.
Source cited by the article: vercel.com/blog/vercel-acquires-better-auth
Couldn’t checkNumber
In October, npm recorded 50.8 million downloads of better-auth and 5.4 million downloads of @better-auth/expo.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “npm recorded 50.8 million downloads of better-auth and 5.4 million of @better-auth/expo”
The source says No passage could be compared.
Source cited by the article: api.npmjs.org/downloads/point/2026-10-01:2026-10-31/better-auth
Matches sourceCausal conclusion
The /expo-authorization-proxy endpoint signed the state value from a caller-supplied URL with the application's secret, checking only that state existed and not that Better Auth had issued it, and required no login.
The cited source says the same thing.
The article says “It checked that state existed, but never checked that Better Auth had issued it”
The source says “const state = url.searchParams.get("state"); if (!state”
Source cited by the article: github.com/better-auth/better-auth/blob/a7b085f305c13aee6df885eebf00fe0a2b68aeae/packages/expo/src/routes.ts
Couldn’t checkCausal conclusion
Because the cookie helper and the email-verification JWTs both used HMAC-SHA256 with the same application secret, a signature from the proxy was accepted by the /verify-email endpoint.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “The cookie helper used HMAC-SHA256 too, with the same application secret”
The source says No passage could be compared.
Source cited by the article: github.com/better-auth/better-auth/blob/a7b085f305c13aee6df885eebf00fe0a2b68aeae/packages/better-auth/src/api/routes/email-verification.ts
Matches sourceGeneralization
The session-cache forgery applies to the compact cookie cache strategy but not the jwe strategy, which uses an HKDF-derived encryption key.
The cited source says the same thing.
The article says “This session-cache forgery does not apply to the jwe strategy: it uses an HKDF-derived encryption key, so the proxy cannot forge those cache tokens”
The source says “jwe`**: Uses JWE (JSON Web Encryption) with A256CBC-HS512 and HKDF key derivation. Fully encrypted tokens - neither readable nor tamperable”
Source cited by the article: better-auth.com/docs/concepts/session-management
Also covered by
No other coverage was clustered with this story.
Elsewhere
Elsewhere: HN 7 pts, not on front page
Recorded for context only, checked 4 Nov 2026, 05:47 UTC. It played no part in the ranking.