better-auth passkey CVE-2025-71400

A valid authenticated session on the better-auth application is required - exploitation is not possible unauthenticated. The target application must have the @better-auth/passkey plugin installed and version must be below 1.4.0. Applications configured with useNumberId: true (auto-incrementing integer passkey IDs) face trivial enumeration; applications using default UUID-based IDs require the attacker to obtain valid passkey IDs through other means (e.g., API leakage, prior reconnaissance), raising the practical attack complexity. No elevated privileges are required beyond a standard user session. There is no required non-default configuration beyond having the passkey plugin enabled.

The CVSS 4.0 score of 7.1 (AV:N/AC:L/AT:N/PR:L/UI:N) reflects a network-accessible, low-complexity flaw requiring only a valid authenticated session - consistent with the description. Integrity impact is rated High (VI:H) because arbitrary passkey deletion degrades the authentication posture of any account in the system; availability impact is Low (VA:L) since victims retain alternative authentication paths. Confidentiality impact is None (VC:N), confirmed by the attack mechanics: the attacker deletes data but does not read it. No EPSS score is provided in the input data, so probabilistic exploitation likelihood cannot be quantified. No KEV listing and no confirmed public exploit code were identified, suggesting opportunistic exploitation has not been observed at scale. Real-world risk is meaningfully elevated for deployments using useNumberId, where the attack degrades to a trivial sequential scan. For UUID-based deployments, risk is lower but not negligible if passkey IDs are exposed elsewhere in the application. The flaw requires authentication, which limits unauthenticated mass exploitation but does not materially protect against insider threats or compromised accounts.

An attacker registers a legitimate account on the target application and obtains a valid session token. Using that session, they iterate over integer passkey IDs (trivially sequential when useNumberId is enabled) and submit POST /passkey/delete-passkey requests for each ID, systematically removing passkeys belonging to all other users. Victims are silently locked out of passkey-based authentication on their next login attempt, potentially driving them to weaker fallback authentication methods.