deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-3824-qmfq-2qv7
Package: surrealdb (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 2.1.0, < 2.1.5
Patched in: 2.1.5

Summary: SurrealDB no JavaScript script function default timeout could facilitate DoS

Details:
Through enabling the scripting capability. SurrealDB allows for advanced functions with complicated logic, by allowing embedded functions to be written in JavaScript.

These functions are bounded for memory and stack size, but not in time. An attacker could launch a number of long running functions that could potentially facilitate a Denial Of Service attack.

This vulnerability can only affect SurrealDB servers explicitly enabling the scripting capability with `--allow-scripting` or
`--allow-all` and equivalent environment variables `SURREAL_CAPS_ALLOW_SCRIPT=true` and `SURREAL_CAPS_ALLOW_ALL=true`.

This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is Low, matched by our CVSS v4 assessment.

### Impact
An attacker can use the scripting capabilities of SurrealDB to run a series of long running functions to facilitate a Denial Of Service attack.

### Patches
A default timeout for the scripting functions has been implemented with a configurable `SURREAL_SCRIPTING_MAX_TIME_LIMIT` environment variable

- Versions 2.0.5, 2.1.5, 2.2.2 and later are not affected by this issue.

### Workarounds
For users that cannot upgrade. Deny execution of embedded scripting functions through the configuration of [capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#capabilities) by starting SurrealDB with the `--deny-scripting` flag or the equivalent environment variable `SURREAL_CAPS_DENY_SCRIPT=true`. This has a usability implication, although scripting functions are disabled by default.

### References
[5597](https://github.com/surrealdb/surrealdb/pull/5597)
[SurrealDB Documentation - Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities)
[SurrealQL Documentation - Scripting Functions](https://surrealdb.com/docs/surrealql/functions/script)
GitHub Security Advisory: GHSA-3824-qmfq-2qv7
Package: surrealdb (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 2.0.5
Patched in: 2.0.5

Summary: SurrealDB no JavaScript script function default timeout could facilitate DoS

Details:
Through enabling the scripting capability. SurrealDB allows for advanced functions with complicated logic, by allowing embedded functions to be written in JavaScript.

These functions are bounded for memory and stack size, but not in time. An attacker could launch a number of long running functions that could potentially facilitate a Denial Of Service attack.

This vulnerability can only affect SurrealDB servers explicitly enabling the scripting capability with `--allow-scripting` or
`--allow-all` and equivalent environment variables `SURREAL_CAPS_ALLOW_SCRIPT=true` and `SURREAL_CAPS_ALLOW_ALL=true`.

This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is Low, matched by our CVSS v4 assessment.

### Impact
An attacker can use the scripting capabilities of SurrealDB to run a series of long running functions to facilitate a Denial Of Service attack.

### Patches
A default timeout for the scripting functions has been implemented with a configurable `SURREAL_SCRIPTING_MAX_TIME_LIMIT` environment variable

- Versions 2.0.5, 2.1.5, 2.2.2 and later are not affected by this issue.

### Workarounds
For users that cannot upgrade. Deny execution of embedded scripting functions through the configuration of [capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#capabilities) by starting SurrealDB with the `--deny-scripting` flag or the equivalent environment variable `SURREAL_CAPS_DENY_SCRIPT=true`. This has a usability implication, although scripting functions are disabled by default.

### References
[5597](https://github.com/surrealdb/surrealdb/pull/5597)
[SurrealDB Documentation - Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities)
[SurrealQL Documentation - Scripting Functions](https://surrealdb.com/docs/surrealql/functions/script)
GitHub Security Advisory: GHSA-3824-qmfq-2qv7
Package: surrealdb (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 2.2.0, < 2.2.2
Patched in: 2.2.2

Summary: SurrealDB no JavaScript script function default timeout could facilitate DoS

Details:
Through enabling the scripting capability. SurrealDB allows for advanced functions with complicated logic, by allowing embedded functions to be written in JavaScript.

These functions are bounded for memory and stack size, but not in time. An attacker could launch a number of long running functions that could potentially facilitate a Denial Of Service attack.

This vulnerability can only affect SurrealDB servers explicitly enabling the scripting capability with `--allow-scripting` or
`--allow-all` and equivalent environment variables `SURREAL_CAPS_ALLOW_SCRIPT=true` and `SURREAL_CAPS_ALLOW_ALL=true`.

This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is Low, matched by our CVSS v4 assessment.

### Impact
An attacker can use the scripting capabilities of SurrealDB to run a series of long running functions to facilitate a Denial Of Service attack.

### Patches
A default timeout for the scripting functions has been implemented with a configurable `SURREAL_SCRIPTING_MAX_TIME_LIMIT` environment variable

- Versions 2.0.5, 2.1.5, 2.2.2 and later are not affected by this issue.

### Workarounds
For users that cannot upgrade. Deny execution of embedded scripting functions through the configuration of [capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#capabilities) by starting SurrealDB with the `--deny-scripting` flag or the equivalent environment variable `SURREAL_CAPS_DENY_SCRIPT=true`. This has a usability implication, although scripting functions are disabled by default.

### References
[5597](https://github.com/surrealdb/surrealdb/pull/5597)
[SurrealDB Documentation - Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities)
[SurrealQL Documentation - Scripting Functions](https://surrealdb.com/docs/surrealql/functions/script)
GitHub Security Advisory: GHSA-3633-g6mg-p6qq
Package: surrealdb (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: < 2.0.5
Patched in: 2.0.5

Summary: SurrealDB memory exhaustion via string::replace using regex 

Details:
An authenticated user can craft a query using the `string::replace` function that uses a Regex to perform a string replacement. As there is a failure to restrict the resulting string length, this enables an attacker to send a `string::replace` function to the SurrealDB server exhausting all the memory of the server due to string allocations. This eventually results in a Denial-of-Service situation for the SurrealDB server.

This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53. Using CVSSv4 definitions, the severity is High. 

### Impact
An authenticated user can crash the SurrealDB instance through memory exhaustion

### Patches
A patch has been created that enforces a limit on string length  `SURREAL_GENERATION_ALLOCATION_LIMIT`

- Versions 2.0.5, 2.1.5, 2.2.2, and later are not affected by this issue

### Workarounds
Affected users who are unable to update may want to limit the ability of untrusted clients to run the `string::replace` function in the affected versions of SurrealDB using the `--deny-functions` flag described within [Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#functions) or the equivalent `SURREAL_CAPS_DENY_FUNC` environment variable.

### References

[SurrealQL Documentation - DB Functions (string::replace)](https://surrealdb.com/docs/surrealql/functions/database/string#stringreplace)
[SurrealDB Documentation - Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#functions)
[SurrealDB Documentation - Environment Variables](https://surrealdb.com/docs/surrealdb/cli/env)
[#5619 ](https://github.com/surrealdb/surrealdb/pull/5619)
[#5638 ](https://github.com/surrealdb/surrealdb/pull/5638)
GitHub Security Advisory: GHSA-3633-g6mg-p6qq
Package: surrealdb (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: >= 2.1.0, < 2.1.5
Patched in: 2.1.5

Summary: SurrealDB memory exhaustion via string::replace using regex 

Details:
An authenticated user can craft a query using the `string::replace` function that uses a Regex to perform a string replacement. As there is a failure to restrict the resulting string length, this enables an attacker to send a `string::replace` function to the SurrealDB server exhausting all the memory of the server due to string allocations. This eventually results in a Denial-of-Service situation for the SurrealDB server.

This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53. Using CVSSv4 definitions, the severity is High. 

### Impact
An authenticated user can crash the SurrealDB instance through memory exhaustion

### Patches
A patch has been created that enforces a limit on string length  `SURREAL_GENERATION_ALLOCATION_LIMIT`

- Versions 2.0.5, 2.1.5, 2.2.2, and later are not affected by this issue

### Workarounds
Affected users who are unable to update may want to limit the ability of untrusted clients to run the `string::replace` function in the affected versions of SurrealDB using the `--deny-functions` flag described within [Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#functions) or the equivalent `SURREAL_CAPS_DENY_FUNC` environment variable.

### References

[SurrealQL Documentation - DB Functions (string::replace)](https://surrealdb.com/docs/surrealql/functions/database/string#stringreplace)
[SurrealDB Documentation - Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#functions)
[SurrealDB Documentation - Environment Variables](https://surrealdb.com/docs/surrealdb/cli/env)
[#5619 ](https://github.com/surrealdb/surrealdb/pull/5619)
[#5638 ](https://github.com/surrealdb/surrealdb/pull/5638)
GitHub Security Advisory: GHSA-3633-g6mg-p6qq
Package: surrealdb (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: >= 2.2.0, < 2.2.2
Patched in: 2.2.2

Summary: SurrealDB memory exhaustion via string::replace using regex 

Details:
An authenticated user can craft a query using the `string::replace` function that uses a Regex to perform a string replacement. As there is a failure to restrict the resulting string length, this enables an attacker to send a `string::replace` function to the SurrealDB server exhausting all the memory of the server due to string allocations. This eventually results in a Denial-of-Service situation for the SurrealDB server.

This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53. Using CVSSv4 definitions, the severity is High. 

### Impact
An authenticated user can crash the SurrealDB instance through memory exhaustion

### Patches
A patch has been created that enforces a limit on string length  `SURREAL_GENERATION_ALLOCATION_LIMIT`

- Versions 2.0.5, 2.1.5, 2.2.2, and later are not affected by this issue

### Workarounds
Affected users who are unable to update may want to limit the ability of untrusted clients to run the `string::replace` function in the affected versions of SurrealDB using the `--deny-functions` flag described within [Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#functions) or the equivalent `SURREAL_CAPS_DENY_FUNC` environment variable.

### References

[SurrealQL Documentation - DB Functions (string::replace)](https://surrealdb.com/docs/surrealql/functions/database/string#stringreplace)
[SurrealDB Documentation - Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#functions)
[SurrealDB Documentation - Environment Variables](https://surrealdb.com/docs/surrealdb/cli/env)
[#5619 ](https://github.com/surrealdb/surrealdb/pull/5619)
[#5638 ](https://github.com/surrealdb/surrealdb/pull/5638)
GitHub Security Advisory: GHSA-ccj3-5p93-8p42
Package: surrealdb (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: < 2.0.5
Patched in: 2.0.5

Summary: SurrealDB server-takeover via SurrealQL injection on backup import

Details:
The SurrealDB command-line tool allows exporting databases through the `export` command. It was discovered that table or field names are not properly sanitized in exports, leading to a SurrealQL injection when the backup is reimported.

For the injection to occur, an authenticated System User with `OWNER` or `EDITOR` roles needs to create tables or fields with malicious names containing SurrealQL, subsequently exported using the `export` operation

The attacker could achieve a privilege escalation and root level access to the SurrealDB instance if a higher privileged user subsequently performs the `import` operation. 

Furthermore, applications using SurrealDB that allow its users to define custom fields or tables are at risk of a universal second order SurrealQL injection, even if query parameters are properly sanitized. 

This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is Critical, matched by our CVSS v4 assessment.

### Impact
This attack can be used to perform privilege escalation and complete takeover (root access) of the SurrealDB instance, as well as being able to perform SurrealQL injection attacks against co-tenanted applications where SurrealDB is used as a shared backend for multiple applications.

### Patches
A patch has been created that addresses the issue by fixing the bugs in the exporter which failed to escape some characters properly.

- Versions 2.0.5, 2.1.5, 2.2.2 and later are not affected by this issue.


### Workarounds
For SurrealDB users that are unable to upgrade, users that are looking to perform `import` operations must manually inspect the exported data for injected statements, prior to importing. 


### References
[SurrealDB Documentation - Export](https://surrealdb.com/docs/surrealdb/cli/export)
[SurrealDB Documentation - Import](https://surrealdb.com/docs/surrealdb/cli/import)
[SurrealDB Documentation - Authentication](https://surrealdb.com/docs/surrealdb/security/authentication)
GitHub Security Advisory: GHSA-ccj3-5p93-8p42
Package: surrealdb (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: >= 2.1.0, < 2.1.5
Patched in: 2.1.5

Summary: SurrealDB server-takeover via SurrealQL injection on backup import

Details:
The SurrealDB command-line tool allows exporting databases through the `export` command. It was discovered that table or field names are not properly sanitized in exports, leading to a SurrealQL injection when the backup is reimported.

For the injection to occur, an authenticated System User with `OWNER` or `EDITOR` roles needs to create tables or fields with malicious names containing SurrealQL, subsequently exported using the `export` operation

The attacker could achieve a privilege escalation and root level access to the SurrealDB instance if a higher privileged user subsequently performs the `import` operation. 

Furthermore, applications using SurrealDB that allow its users to define custom fields or tables are at risk of a universal second order SurrealQL injection, even if query parameters are properly sanitized. 

This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is Critical, matched by our CVSS v4 assessment.

### Impact
This attack can be used to perform privilege escalation and complete takeover (root access) of the SurrealDB instance, as well as being able to perform SurrealQL injection attacks against co-tenanted applications where SurrealDB is used as a shared backend for multiple applications.

### Patches
A patch has been created that addresses the issue by fixing the bugs in the exporter which failed to escape some characters properly.

- Versions 2.0.5, 2.1.5, 2.2.2 and later are not affected by this issue.


### Workarounds
For SurrealDB users that are unable to upgrade, users that are looking to perform `import` operations must manually inspect the exported data for injected statements, prior to importing. 


### References
[SurrealDB Documentation - Export](https://surrealdb.com/docs/surrealdb/cli/export)
[SurrealDB Documentation - Import](https://surrealdb.com/docs/surrealdb/cli/import)
[SurrealDB Documentation - Authentication](https://surrealdb.com/docs/surrealdb/security/authentication)
GitHub Security Advisory: GHSA-ccj3-5p93-8p42
Package: surrealdb (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: >= 2.2.0, < 2.2.2
Patched in: 2.2.2

Summary: SurrealDB server-takeover via SurrealQL injection on backup import

Details:
The SurrealDB command-line tool allows exporting databases through the `export` command. It was discovered that table or field names are not properly sanitized in exports, leading to a SurrealQL injection when the backup is reimported.

For the injection to occur, an authenticated System User with `OWNER` or `EDITOR` roles needs to create tables or fields with malicious names containing SurrealQL, subsequently exported using the `export` operation

The attacker could achieve a privilege escalation and root level access to the SurrealDB instance if a higher privileged user subsequently performs the `import` operation. 

Furthermore, applications using SurrealDB that allow its users to define custom fields or tables are at risk of a universal second order SurrealQL injection, even if query parameters are properly sanitized. 

This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is Critical, matched by our CVSS v4 assessment.

### Impact
This attack can be used to perform privilege escalation and complete takeover (root access) of the SurrealDB instance, as well as being able to perform SurrealQL injection attacks against co-tenanted applications where SurrealDB is used as a shared backend for multiple applications.

### Patches
A patch has been created that addresses the issue by fixing the bugs in the exporter which failed to escape some characters properly.

- Versions 2.0.5, 2.1.5, 2.2.2 and later are not affected by this issue.


### Workarounds
For SurrealDB users that are unable to upgrade, users that are looking to perform `import` operations must manually inspect the exported data for injected statements, prior to importing. 


### References
[SurrealDB Documentation - Export](https://surrealdb.com/docs/surrealdb/cli/export)
[SurrealDB Documentation - Import](https://surrealdb.com/docs/surrealdb/cli/import)
[SurrealDB Documentation - Authentication](https://surrealdb.com/docs/surrealdb/security/authentication)
GitHub Security Advisory: GHSA-2cvj-g5r5-jrrg
Package: surrealdb (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 2.1.5
Patched in: 2.1.5

Summary: SurrealDB has local file read of 2-column TSV files via analyzers 

Details:
An authenticated system user at the root, namespace, or database levels can use the `DEFINE ANALYZER` statement to point to arbitrary file locations on the file system, and should the file be tab separated with two columns, the analyzer can be leveraged to exfiltrate the content.

This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is Low, matched by our CVSS v4 assessment.

### Impact
Limited to unauthorised access to 2 column TSV files on the file system

### Patches
A patch has been created that introduces a new environment variable, `SURREAL_FILE_ALLOWLIST` , which contains a list of allowed file paths. When a mapping file is processed, the mapper checks if the file’s path is within one of the allowed paths.

- Versions 2.1.5, 2.2.2 and later are not affected by this issue.

### Workarounds
Users unable to update may want to limit those with root, namespace, or database level users to trusted parties only.

### References
[SurrealQL Documentation - DEFINE ANALYZER](https://surrealdb.com/docs/surrealql/statements/define/analyzer#define-analyzer-statement)
[#5600](https://github.com/surrealdb/surrealdb/pull/5600)
GitHub Security Advisory: GHSA-2cvj-g5r5-jrrg
Package: surrealdb (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 2.2.0, < 2.2.2
Patched in: 2.2.2

Summary: SurrealDB has local file read of 2-column TSV files via analyzers 

Details:
An authenticated system user at the root, namespace, or database levels can use the `DEFINE ANALYZER` statement to point to arbitrary file locations on the file system, and should the file be tab separated with two columns, the analyzer can be leveraged to exfiltrate the content.

This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is Low, matched by our CVSS v4 assessment.

### Impact
Limited to unauthorised access to 2 column TSV files on the file system

### Patches
A patch has been created that introduces a new environment variable, `SURREAL_FILE_ALLOWLIST` , which contains a list of allowed file paths. When a mapping file is processed, the mapper checks if the file’s path is within one of the allowed paths.

- Versions 2.1.5, 2.2.2 and later are not affected by this issue.

### Workarounds
Users unable to update may want to limit those with root, namespace, or database level users to trusted parties only.

### References
[SurrealQL Documentation - DEFINE ANALYZER](https://surrealdb.com/docs/surrealql/statements/define/analyzer#define-analyzer-statement)
[#5600](https://github.com/surrealdb/surrealdb/pull/5600)