GHSA-5353-f8fq-65vc
MEDIUMGHSA-5353-f8fq-65vc is a medium-severity (CVSS 4.9) Improper Authentication vulnerability in github.com/QuantumNous/new-api. O3 Security confirms whether GHSA-5353-f8fq-65vc is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
New API has passkey-based secure step-up verification bypass for root-only channel secret disclosure
Real-World Exposure
github.com/QuantumNous/new-apiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/QuantumNous/new-api | ≥ 0.10.0 | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/QuantumNous/new-api. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of github.com/QuantumNous/new-api has shipped for GHSA-5353-f8fq-65vc yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-5353-f8fq-65vc is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-5353-f8fq-65vc. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-5353-f8fq-65vc in your dependencies?
O3 detects GHSA-5353-f8fq-65vc across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.