GHSA-5353-F8FQ-65VC
Vulnerability from github – Published: 2026-03-23 19:56 – Updated: 2026-03-30 14:06Summary
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.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/QuantumNous/new-api"
},
"ranges": [
{
"events": [
{
"introduced": "0.10.0"
},
{
"last_affected": "0.11.9-alpha.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32879"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-23T19:56:00Z",
"nvd_published_at": "2026-03-23T20:16:27Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nA 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.\n\n## Affected versions\n\n\u003e= v0.10.0\n\n## Description\n\nThe `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.\n\nAs 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.\n\n## Impact\n\nIn 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.\n\nSuccessful exploitation requires:\n- an already authenticated session for the target account, and\n- a registered passkey on that account.\n\nNo 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.\n\n## Workarounds\n\nUntil a patched release is applied:\n- do not rely on passkey as the step-up method for privileged secure-verification actions;\n- require TOTP/2FA for those actions where operationally possible; or\n- temporarily restrict access to affected secure-verification-protected endpoints.",
"id": "GHSA-5353-f8fq-65vc",
"modified": "2026-03-30T14:06:18Z",
"published": "2026-03-23T19:56:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/QuantumNous/new-api/security/advisories/GHSA-5353-f8fq-65vc"
},
{
"type": "PACKAGE",
"url": "https://github.com/QuantumNous/new-api"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "New API has passkey-based secure step-up verification bypass for root-only channel secret disclosure"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.