CVE-2026-32879
Logic Flaw in New API Passkey Verification Enables Bypass
Publication date: 2026-03-23
Last updated on: 2026-03-25
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| newapi | new_api | From 0.10.0 (inc) to 0.11.9 (exc) |
| newapi | new_api | 0.11.9 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-287 | When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': 'CVE-2026-32879 is a moderate severity vulnerability in the QuantumNous new-api Go package starting from version 0.10.0. It involves a logic flaw in the passkey-based secure step-up verification process.'}, {'type': 'paragraph', 'content': 'Specifically, when a request is made to the POST /api/verify endpoint with the method set to "passkey", the server does not perform the full WebAuthn assertion challenge/response as intended. Instead, it only checks if the authenticated user’s account has a registered passkey and prematurely marks the secure verification as complete.'}, {'type': 'paragraph', 'content': 'This flaw allows an authenticated user who already has a valid session and a registered passkey to bypass the intended secure verification step without completing the actual passkey challenge.'}, {'type': 'paragraph', 'content': 'The vulnerability affects actions protected by the SecureVerificationRequired() middleware, such as the root-only POST /api/channel/:id/key endpoint, which returns sensitive channel secrets.'}, {'type': 'paragraph', 'content': 'Exploitation requires the attacker to already be authenticated on the target account and have a registered passkey; no full login bypass or cross-account privilege escalation has been confirmed.'}] [1]
How can this vulnerability impact me? :
This vulnerability can allow an authenticated user with a registered passkey to bypass the secure verification step that is meant to protect privileged operations.
As a result, the user could perform sensitive actions without completing the intended step-up verification, potentially accessing sensitive information such as channel secrets.
However, exploitation requires the attacker to already have an authenticated session and a registered passkey on the target account, so it does not allow full login bypass or cross-account privilege escalation.
Until a patched version is available, it is recommended to avoid using passkey as the step-up verification method for privileged actions, enforce TOTP/2FA where possible, or restrict access to affected endpoints.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability involves a logic flaw in the POST /api/verify endpoint when the request specifies {"method":"passkey"}. Detection would involve monitoring or inspecting requests to this endpoint to see if the passkey method is used for secure verification.'}, {'type': 'paragraph', 'content': 'Specifically, you can look for authenticated sessions where the secure verification step is marked complete without a full WebAuthn assertion challenge/response.'}, {'type': 'paragraph', 'content': 'Since the vulnerability requires an authenticated user with a registered passkey, commands or tools that log or analyze API requests to /api/verify with method=passkey could help detect potential exploitation attempts.'}, {'type': 'paragraph', 'content': 'No explicit commands are provided in the available resources, but network traffic inspection tools (e.g., tcpdump, Wireshark) or API gateway logs filtering for POST requests to /api/verify with JSON payload containing "method":"passkey" would be a starting point.'}] [1]
What immediate steps should I take to mitigate this vulnerability?
Since no patched versions are available at the time of disclosure, immediate mitigation steps include:
- Do not rely on passkey as the step-up verification method for privileged secure-verification actions.
- Require TOTP (Time-based One-Time Password) or other forms of two-factor authentication (2FA) for those privileged actions where operationally possible.
- Temporarily restrict access to affected secure-verification-protected endpoints, such as POST /api/channel/:id/key, until a patched release is available.