GHSA-g3qj-j598-cxmq is a high-severity (CVSS 7.5) vulnerability in fido2-lib. A fix is available for fido2-lib — see the affected versions and patch details below.
fido2-lib is vulnerable to DoS via cbor-extract heap buffer over-read in CBOR attestation parsing
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
fido2-libnpmDescription
Summary
fido2-lib v3.x depends on cbor-x (~1.6.0), which optionally pulls in cbor-extract (C++ native addon). cbor-extract <= 2.2.0 has a heap buffer over-read in extractStrings() — a 5-byte CBOR payload crashes Node.js with SIGSEGV. No JS exception, no try/catch, process dead.
The crash triggers during WebAuthn registration when the server decodes the attestation object. An attacker sends a crafted authenticator response to the registration endpoint — single request, unauthenticated, instant kill.
Fixed in [email protected] / [email protected] (2026-03-08). [email protected] still pins cbor-x ~1.6.0 which resolves to vulnerable cbor-extract.
Affected versions
fido2-lib <= 3.5.7 (introduced cbor-x dependency). fido2-lib 2.x uses the old cbor package — not affected.
Only affects systems where cbor-extract native addon is installed (prebuilt binary available for platform). Pure JS fallback is safe.
PoC
const { decode } = require("cbor-x");
decode(Buffer.from("7a10000000", "hex")); // exit code 139 (SIGSEGV)
CBOR text string header claiming 268MB in a 5-byte buffer. extractStrings() in extract.cpp line 87 calls readString() without bounds check. Reads past buffer into unmapped memory.
In context: attacker intercepts WebAuthn registration response, replaces attestationObject with the 5-byte payload, POSTs to the registration verification endpoint. Server calls attestationResult() → cbor-x.decode() → cbor-extract → SIGSEGV.
Fix
Bump cbor-x to >= 1.6.3 (which pulls cbor-extract >= 2.2.1).
-"cbor-x": "~1.6.0"
+"cbor-x": "^1.6.3"
— Malik X (@Xvush)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | fido2-lib | all versions | 3.5.8npm install fido2-lib@3.5.8 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for fido2-lib, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update fido2-lib to 3.5.8 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-g3qj-j598-cxmq is resolved across your whole dependency graph.
Workarounds
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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-g3qj-j598-cxmq can be triaged on real exposure rather than presence alone.
Tailored to GHSA-g3qj-j598-cxmq. 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-g3qj-j598-cxmq in your dependencies?
O3 Security finds GHSA-g3qj-j598-cxmq across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.