Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-63761

CVE-2026-63761: SurrealDB JWT Auth Bypass Vulnerability

CVE-2026-63761 is an authentication bypass flaw in SurrealDB that silently substitutes ES384 for ES512 in JWT configurations, causing authentication failures. This article covers technical details, affected versions, and mitigation.

Published:

CVE-2026-63761 Overview

CVE-2026-63761 affects SurrealDB versions before 3.1.0. The database silently substitutes the ES384 algorithm when administrators configure a JSON Web Token (JWT) access method with ALGORITHM ES512. The underlying jsonwebtoken crate (v10.x) contains no ES512 variant, and the mapping defaults to ES384 without any error, warning, or log entry. Operators who supply a correct P-521 key for ES512 experience authentication handshake failures because ES384 expects a P-384 curve. Tokens issued by SurrealDB are also rejected by external systems that expect genuine ES512 signatures. The flaw does not enable token forgery or compromise data confidentiality, since ES384 remains cryptographically sound.

Critical Impact

Silent algorithm downgrade breaks JWT-based authentication and interoperability with external identity systems relying on ES512 signatures.

Affected Products

  • SurrealDB versions prior to 3.1.0
  • SurrealDB deployments using DEFINE ACCESS ... TYPE JWT ALGORITHM ES512
  • Downstream services relying on ES512 signatures issued or validated by SurrealDB

Discovery Timeline

  • 2026-07-20 - CVE-2026-63761 published to the National Vulnerability Database (NVD)
  • 2026-07-22 - CVE-2026-63761 last modified in NVD

Technical Details for CVE-2026-63761

Vulnerability Analysis

CVE-2026-63761 is a cryptographic configuration weakness classified under [CWE-327] (Use of a Broken or Risky Cryptographic Algorithm). The issue is not that ES384 is weak, but that SurrealDB silently accepts the ES512 configuration keyword and substitutes a different algorithm. Administrators who explicitly select ES512 to align with an organizational cryptographic standard receive ES384 instead. This mismatch surfaces only when authentication handshakes fail or when external verifiers reject the signature.

The fault surface is limited to signing and validation paths for JWT access methods defined at the database level. Because the substitution is silent, monitoring and audit logs contain no evidence of the algorithm change. The vulnerability produces an availability impact on authentication workflows but does not degrade the strength of the underlying signature.

Root Cause

SurrealDB's algorithm mapping layer bridges its SurrealQL configuration syntax to the jsonwebtoken Rust crate at version 10.x. That crate exposes ES256 and ES384 but does not implement ES512. Instead of returning a configuration error for the unsupported value, the mapping falls through to ES384 as a default. No log entry, warning, or startup diagnostic is emitted, so the misconfiguration remains invisible to operators.

Attack Vector

CVE-2026-63761 requires authenticated configuration privileges to define the JWT access method. An attacker cannot leverage this issue to forge tokens or bypass authentication. The realistic impact is operational: broken authentication flows, denial of service against JWT-dependent clients, and confusion during incident response when signature verification fails on downstream systems. Refer to the SurrealDB GitHub Security Advisory GHSA-fwg2-gr34-q3w8 and the VulnCheck advisory for full technical details.

// No verified proof-of-concept code is available. The flaw is a
// configuration-time algorithm substitution documented in the
// SurrealDB security advisory referenced above.

Detection Methods for CVE-2026-63761

Indicators of Compromise

  • SurrealDB access method definitions containing ALGORITHM ES512 on releases prior to 3.1.0
  • JWT signatures issued by SurrealDB carrying an alg header of ES384 when ES512 was requested
  • Authentication handshake failures correlated with P-521 keys supplied to SurrealDB
  • External verifiers logging signature validation errors for tokens minted by SurrealDB

Detection Strategies

  • Inspect SurrealQL schema exports for DEFINE ACCESS ... TYPE JWT ALGORITHM ES512 and cross-check the running SurrealDB version.
  • Decode tokens produced by SurrealDB and compare the JWT header alg value against the configured algorithm.
  • Enumerate installed SurrealDB binaries across environments and flag any build below 3.1.0.

Monitoring Recommendations

  • Alert on repeated JWT verification failures at API gateways and identity brokers consuming SurrealDB tokens.
  • Log all changes to DEFINE ACCESS statements and review them during configuration audits.
  • Track SurrealDB version inventory through the EPSS score of 0.163% as a low-urgency but persistent hygiene item.

How to Mitigate CVE-2026-63761

Immediate Actions Required

  • Upgrade SurrealDB to version 3.1.0 or later, where the mapping either supports ES512 or rejects unsupported algorithms explicitly.
  • Audit every JWT access method definition and confirm the configured algorithm matches the key material in use.
  • Rotate P-521 keys that were paired with a failing ES512 configuration and re-issue matching P-384 keys if ES384 is acceptable.

Patch Information

SurrealDB addressed CVE-2026-63761 in release 3.1.0. Consult the SurrealDB GitHub Security Advisory GHSA-fwg2-gr34-q3w8 for the fix commit and upgrade guidance. Operators running clustered deployments should upgrade all nodes to keep signing behavior consistent.

Workarounds

  • Replace ALGORITHM ES512 with ALGORITHM ES384 and provision a P-384 key until the upgrade is complete.
  • Switch the JWT access method to RS256 or EdDSA where downstream systems support them and ES512 is not mandatory.
  • Isolate the SurrealDB JWT issuance path behind a proxy that re-signs tokens with the required ES512 signature using a compliant library.
bash
# Configuration example: use an algorithm that SurrealDB implements natively
# on releases prior to 3.1.0, then plan the upgrade to 3.1.0+.
DEFINE ACCESS api_access ON DATABASE TYPE JWT
  ALGORITHM ES384
  KEY "-----BEGIN PUBLIC KEY-----\n...P-384 key...\n-----END PUBLIC KEY-----"
  DURATION FOR TOKEN 1h;

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.