@BETTER-AUTH/PASSKEY · GHSA-gv75-j3v8-3crm · Package
FIX → 1.8.0-beta.5 · 1.4.0 +1
The passkey plugin in @better-auth/passkey and better-auth took the expected WebAuthn origin from the request rather than server configuration, and did not confirm PIN or biometric checks when userVerification is required. An attacker on another origin under the same relying party ID could have a passkey response accepted, and a user could register or use a passkey without the required user verification.
first public Nov 3, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Applications that use the better-auth passkey plugin and either require user verification (userVerification set to "required") or use a relying party ID that covers origins the team does not control. The sources describe the request-origin problem as applying where the RP ID spans other subdomains; apps on the default "preferred" setting with a tightly scoped RP ID are not described as exposed to the verification bypass.
Not affected if default-config, no-passkey-plugin
Who cares better-auth, node, passkeys, webauthn
@better-auth/passkey (for example npm ls @better-auth/passkey) and of better-auth.authenticatorSelection.userVerification set to in the passkey configuration.You are affected if you use @better-auth/passkey 1.4.0-beta.16 or later, or the passkey plugin built into better-auth before 1.4.0, and any of these is true:
authenticatorSelection.userVerification to "required".User verification. With userVerification: "required", the server asked the authenticator to verify the user, for example with a PIN or fingerprint, but did not confirm that it happened. The default "preferred" setting allows responses without this check by design.
Origin. The server took the expected WebAuthn origin from the request instead of from its configuration.
A user can register or use a passkey without the PIN or biometric check your application requires. A passkey response created on another origin under the same relying party ID could be accepted. Neither problem lets anyone register a passkey for another user's account or skip the sign-in needed to register one.
Upgrade to 1.7.16, or to 1.8.0-beta.5 on the beta line.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
"required"rpID) covers origins you do not control, such as other subdomains.Upgrade to 1.8.0-beta.5 · 1.4.0 +1
@better-auth/passkey: 1.7.16 on the stable line, or 1.8.0-beta.5 on the beta line.better-auth: 1.4.0 (the built-in passkey plugin before 1.4.0 is affected).origin option when rpID is set and a wildcard in baseURL.allowedHosts covers it.@better-auth/passkeyThe expected origin now comes from the origin option, or from the baseURL origin plus a frontend origin listed exactly in trustedOrigins. Set origin when rpID is set and a wildcard in baseURL.allowedHosts covers it. userVerification now also applies to authentication.
None verified beyond upgrading.
The registration and authentication handlers passed the request's origin to WebAuthn verification and did not set the required user verification flag. They now use the configured origin and require the user verification flag when userVerification is "required".