Fix(auth): Prevent Unauthenticated DoS via Passkey Challenge Store Growth

[security] fix(auth): cap pending passkey challenges #3624 Vulnerability Overview This PR restricts the bounds of public passkey options to prevent unauthenticated clients from infinitely growing the WebAuthn challenge storage. Impact Issue: Unauthenticated passkey option challenge storage growth Impact: A reachable WebUI with passkeys enabled on a client may be forced to repeatedly rewrite a growing file, increasing CPU/disk I/O and degrading login availability. Severity: Medium Fix Details Global and per-WebAuthn context limits: Limits pending passkey challenges both globally and per WebAuthn context before generating new challenges. Return 429: Returns HTTP 429 when the challenge storage limit is reached, instead of rewriting a growing JSON file. Locking mechanism: Adds a lock to prevent race conditions between challenge storage mutations and concurrent options/login operations. Regression tests: Adds regression tests for challenge limits and the HTTP 429 route contract. Attack Flow Affected Code Issue: Passkey challenge storage growth Files: , , Root Cause Issue: Unauthenticated passkey option challenge storage growth Reasons: - The options endpoint is public by design, but generating options also allocates persistent local challenge state. - The challenge storage has TTL cleanup but lacks global or per-context limits. - Failed login assertions are rate-limited later, but after the challenge has already been allocated. CVSS Evaluation Issue: Unauthenticated passkey option challenge storage growth CVSS v3.1: 5.3 Medium Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L Security Reproduction Steps 1. Challenge storage growth in vulnerable code - Enable authentication and passkeys, and register at least one passkey credential. - Send repeated requests without completing the passkey assertion. - Observe the file growing with pending entries and being rewritten with each request. Expected Vulnerable Behavior The pre-patch server continues to add a challenge for every options request. The challenge file grows linearly until TTL cleanup. No route-level 429 responses are returned for challenge allocation pressure. Changes in This PR Adds to limit challenge storage rejection. Adds and limits. Applies these limits after expired challenge cleanup. Adds to protect the storage/consumption path for challenge load/update/write operations. Returns HTTP 429 from login and registration options routes when the challenge limit is reached. Adds regression tests to verify per-context limit behavior and route-level 429 wiring. File Changes Category: Passkey Challenge Storage - File: - Change: Adds bounded challenge storage and synchronized mutations. Category: API Responses - File: - Change: Converts limit failures to HTTP 429 responses for the passkey options route. Category: Regression Tests - File: - Change: Covers limit behavior and route 429 wiring. Maintainer Impact The patch is intentionally scoped to passkey challenge storage and passkey options route handling. Non-passkey logins and registrations continue to work when the number of pending challenges is below the limit. Limits only affect excessive pending challenges within the same WebAuthn context or across processes. Password authentication, session handling, frontend panels, and unrelated APIs remain unchanged. Rationale for Fix The challenge storage is a persistent boundary because resource allocation occurs at options generation, before any passkey assertion can be verified or login failure rate limits applied. Returning 429 provides a clear signal to the client while preventing unbounded local JSON growth. Per-context limits keep repeated requests for the same RP/origin/kind bounded, while global limits protect overall process state if requests are distributed across contexts. Change Type Security Fix Tests Documentation Update Refactoring, no behavior change Test Plan Execution: Result: 18 passed, 1 warning in 2.24s Disclosure Statement This PR bounds the availability hardening of passkey option challenge storage. Assumes WebAuthn and passkey support are enabled, and HTTP endpoints are reachable by the attacker. No production systems, real passkey credentials, or destructive payloads were used for verification. No unrelated file changes.

Goal Reached Thanks to every supporter — we hit 100%!

Fix(auth): Prevent Unauthenticated DoS via Passkey Challenge Store Growth

More from this source