SurrealDB before 3.1.0 silently substitutes the ES384 algorithm when a JWT access method is configured with ALGORITHM ES512 (DEFINE ACCESS ... TYPE JWT ALGORITHM ES512), because the underlying jsonwebtoken crate (v10.x) has no ES512 variant and the mapping defaults to ES384 without any error, warning, or log message. Users who supply the correct P-521 key for ES512 experience authentication handshake failures due to the curve mismatch with ES384 (which expects P-384), and tokens are rejected by external systems expecting genuine ES512 signatures. The flaw cannot be used to forge tokens or compromise data confidentiality or integrity, as ES384 remains cryptographically strong.
Fix
Patch, vendor advisory and mitigation references on NVD 1
- https://github.com/surrealdb/surrealdb/security/advisories/GHSA-fwg2-gr34-q3w8 Mitigation, Vendor Advisory
Every line above is quoted from NVD, CISA, Microsoft, the vendor's own advisory or DISA; nothing is generated.
Change history 1
- First seenCVSS 5.3 · surrealdbNVD modified 2026-10-08 16:17
Affected (CPE criteria) 1
cpe:2.3:a:surrealdb:surrealdb:*:*:*:*:*:*:*:*
References 2
- https://github.com/surrealdb/surrealdb/security/advisories/GHSA-fwg2-gr34-q3w8 Mitigation, Vendor Advisory
- https://www.vulncheck.com/advisories/surrealdb-before-algorithm-downgrade-via-es512 Third Party Advisory