Version	Supported
< 2.0	-
>= 2.0.0

We take the security of SurrealDB code, software, and infrastructure very seriously. If you believe you have found a security vulnerability in SurrealDB, we encourage you to let us know right away. We will investigate all legitimate reports and do our best to quickly fix the problem.

Please report any issues or vulnerabilities via Github Security Advisories instead of posting a public issue in GitHub. You can also send security communications to security@surrealdb.com. Please include the version identifier obtained by running surreal version on the command line and details on how the vulnerability can be exploited.

• ✅ Privately disclose the details of any potential vulnerability to SurrealDB.
• ✅ Provide enough information to reproduce the vulnerability in your report.
• ✅ Ask permission from SurrealDB to run automated security tools against its infrastructure.

• ❌ Disclose the details of the vulnerability publicly or to third parties.
• ❌ Exploit a vulnerability beyond what is strictly necessary to verify its existence.
• ❌ Run automated security tools against SurrealDB infrastructure without permission.

• Acknowledge your report within 3 business days of the date of communication.
• Verify the issue and keep you informed of the progress toward its resolution.
• Handle your report and any data you share with us with strict confidentiality.
• Abstain from legal action against you for any report made following this policy.
• Credit you in any relevant public security advisory, unless you desire otherwise.

SurrealDB strives to provide timely and clear communication regarding any security issues that may impact users of its binaries, libraries and platforms using Github Security Advisories and other available communication channels. Generally, vulnerabilities will be discussed and resolved privately to minimize the risk of exploitation. Security advisories will generally be published once a SurrealDB version including a fix for the relevant vulnerability is available. The goal of publishing security advisories is to notify users of the risks involved with using a vulnerable version and to provide information for resolving the issue or implementing any possible workarounds.

Vulnerabilities in third-party dependencies may only be independently published by SurrealDB when they affect a SurrealDB binary or platform. In those cases, the original CVE identifier will be referenced. Vulnerabilities affecting SurrealDB libraries will not be published again by SurrealDB when an advisory already exists for the original dependency as security tooling (e.g. cargo audit, or cargo deny check or Dependabot) will already be able to track it up the dependency tree.

As with any other update, security updates to SurrealDB are released following Semantic Versioning (AKA SemVer).

Urgent security patches will be released for the latest SurrealDB minor release (e.g. 2.999.0) using a patch release (e.g. 2.999.1). We commit not to break API backward compatibility in patch releases to ensure that SurrealDB users have no reservations that may cause delays when applying security patches.

Regular security updates can be released as part of a minor release (e.g. 2.999.0 to 2.1000.0). Minor releases should not break backward compatibility either and we encourage updating whenever possible. However, there are a few security-sensitive dependencies (e.g. rustls or native_tls) that are part of the public API of SurrealDB but are still in an unstable version, meaning that they can break backward compatibility. We do not consider these types (e.g. the TLS enumeration) part of the SurrealDB stable API and as such their backward compatibility may be broken in a minor release. These breaking changes should be rare and will always be clearly stated in the changelog. Even if not considered part of the stable API, these types of breaking changes will only be included in major and minor releases; never in patch releases as stated in the previous paragraph.

Dependencies used by SurrealDB are checked for known vulnerabilities in CI using cargo deny check. Developers are required to either update, replace or acknowledge vulnerable dependencies found during the approval process of every pull request. Additionally, SurrealDB makes use of Github's Dependabot alerts to continuously monitor its dependencies for security issues.

SurrealDB also implements basic supply chain security practices using cargo-vet and cargo-acl (i.e. Cackle) to mitigate the impact of attackers introducing malicious code into third-party dependencies. These tools are executed as part of the CI process to ensure that significant changes in dependencies are considered. More details about these practices can be found here.

SurrealDB is integrated with Google's OSS-Fuzz project. As part of this integration, both the SurrealQL parser and query executor are continuously fuzzed to identify security and performance bugs in SurrealQL. We aim to resolve all security-relevant bugs before their disclosure deadline. Other bugs (e.g. crashes or performance bugs) that may have some availability impact will be prioritized and resolved as any other bug regardless of the disclosure deadline.