GHSA-5353-f8fq-65vc New API has passkey-based secure step-up verification bypass for root-only channel secret disclosure

• Go github.com/QuantumNous/new-api: >= 0.10.0, <= 0.11.9-alpha.1 (no fix yet)

Summary A logic flaw in the universal secure verification flow allows an authenticated user with a registered passkey to satisfy secure verification without completing a WebAuthn assertion. Affected versions >= v0.10.0 Description The `POST /api/verify` endpoint supports multiple secure verification methods, including passkeys. When the request body contains `{"method":"passkey"}`, the server only checks whether the authenticated account has a passkey record on file and then marks the secure verification session as complete. It does not verify that the requester successfully completed a WebAuthn assertion. As a result, an authenticated user who already has a valid session and a registered passkey can satisfy the secure verification requirement without performing the intended passkey challenge/response flow. Impact In the upstream project, this issue affects actions protected by `SecureVerificationRequired()`. At the time of publication, the confirmed upstream impact is the root-only `POST /api/channel/:id/key` endpoint, which returns stored channel secrets. Successful exploitation requires: • an already authenticated session for the target account, and • a registered passkey on that account. No full login bypass or cross-account privilege escalation has been confirmed in the upstream codebase. However, the issue defeats the intended step-up verification control for affected privileged actions. Workarounds Until a patched release is applied: • do not rely on passkey as the step-up method for privileged secure-verification actions; • require TOTP/2FA for those actions where operationally possible; or • temporarily restrict access to affected secure-verification-protected endpoints.