CVE-2026-63761 in SurrealDB
Summary
by MITRE • 07/20/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/20/2026
This vulnerability exists in SurrealDB versions prior to 3.1.0 where a critical configuration mismatch occurs when implementing JWT authentication with the ES512 algorithm. The underlying jsonwebtoken crate version 10.x lacks native support for the ES512 elliptic curve signature algorithm, creating a silent substitution behavior that defaults to ES384 without any error messaging or logging notifications to alert administrators of the discrepancy. When users configure access methods using DEFINE ACCESS ... TYPE JWT ALGORITHM ES512, the system automatically reverts to ES384 implementation while maintaining the original algorithm specification in the configuration, leading to a false sense of security and proper implementation.
The technical flaw manifests through improper error handling and validation within the authentication layer where cryptographic algorithm mappings are not properly validated against available implementations. This creates a scenario where administrators believe they have correctly configured ES512 signatures using P-521 keys, but the system silently transforms these requests to use ES384 with P-384 curves. The mismatch between expected and actual cryptographic parameters causes authentication handshake failures as the system attempts to verify signatures against incompatible elliptic curves. This behavior violates the principle of least surprise and creates operational confusion for security administrators who expect explicit error reporting when configuration mismatches occur.
Operational impact of this vulnerability extends beyond simple authentication failures to create potential security misconfigurations that could be exploited in certain scenarios. While the flaw does not directly enable token forgery or compromise data confidentiality, it creates a situation where external systems expecting genuine ES512 signatures will reject tokens generated by the system due to algorithm mismatches. This can lead to denial of service conditions for legitimate users and may mask actual security issues that should trigger alerts. The silent substitution behavior also prevents proper audit logging and monitoring of cryptographic configuration changes, making it difficult for security teams to detect misconfigurations in their authentication infrastructure.
The vulnerability aligns with CWE-200 (Information Exposure) and CWE-1037 (Insufficiently Protected Credentials) categories as it creates a scenario where authentication mechanisms operate with reduced security strength without proper notification. From an ATT&CK perspective, this maps to T1566 (Phishing) and T1078 (Valid Accounts) where misconfigured authentication systems could potentially be leveraged to bypass security controls through legitimate but incorrectly configured access methods. Organizations relying on SurrealDB for authentication may experience unexpected service disruptions when external systems enforce strict signature algorithm requirements, particularly in environments where compliance frameworks mandate specific cryptographic standards.
Mitigation strategies should include immediate upgrade to SurrealDB 3.1.0 or later versions that properly handle algorithm validation and error reporting. Administrators must implement comprehensive monitoring of authentication failures and cryptographic operations to detect configuration mismatches. The system should be configured to explicitly validate cryptographic algorithm implementations against available libraries, with mandatory logging of all algorithm substitutions. Additionally, security teams should conduct regular audits of JWT configurations and ensure proper testing of authentication flows with external systems to verify signature compatibility. Organizations should also implement automated alerting for any cryptographic algorithm changes that do not match expected configuration parameters, as this vulnerability demonstrates how silent failures can create operational security gaps.